(12) NACH DEIVfWRTRAG USER DIE INTERNATIONALE ZUSAMMWARBEIT AUF DEM GEBIET DES 
PATENTWESENS (PCT) VEROFFENTLICHTE INTERNATIONALE ANMELDUNG 



(19) Weltorganisation flir geistiges Eigentum 
Internationales Biiro 

(43) Internationales Veroffentlichungsdatum 
19. Februar 2004 (19.02,2004) 




PCT 



mini 



mi 



(10) Internationale Veroffentlichungsnummer 

WO 2004/014700 Al 



(51) Internationale Patentklassffikation 7 : B60R 16/02, 
B60K 41/00 

(21) Internationales Aktenzeichen: PCT/DE2003/002541 

(22) Internationales Anmeldedatum: 

29. Juli 2003 (29.07.2003) 



(25) Einreichungssprache: 

(26) Veroffentlichungssprache: 



Deutsch 
Deutsch 



(30) Angaben zur Prioritat: 

102 34 635.6 29. Juli 2002 (29.07.2002) DE 

103 34 536.1 29. Juli 2003 (29.07.2003) DE 

(71) Anmelder (fur alle Bestimmungsstaaten mit Ausnahme von 
US): ROBERT BOSCH GMBH [DE/DE] ; Postfach 30 02 
20, 70442 Stuttgart (DE). 



(72) ErGnder; und 

(75) Erfinder/Anmelder (nur fur US): BASSIERE, Dirk 

[DE/DE]; Karlsstrasse 42, 71679 Asperg (DE). BICK- 
ENDORF, Frank [DE/DE]; Wolf-Hirth-Strasse 1, 71254 
Ditzingen (DE). FREI, Rasmus [DE/DE]; Farbstrasse 
9/1, 74321 Bietigheim-Bissingen (DE). 

(74) Gemeinsamer Vertreter: ROBERT BOSCH GMBH; 

Postfach 30 02 20, 70442 Stuttgart (DE). 

(81) Bestimmungsstaaten (national): JP, US. 

(84) Bestimmungsstaaten ( regional): europaisches Patent (AT, 
BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, 
HU, IE, IT, LU, MC, NL, PT, RO, SE, SI, SK, TR). 

Veroflentlicht: 

— mit intemationalem Recherchenbericht 

[Fortsetzjung aufder ndchsten Seite] 



(54) Title : COMPUTE R_SXSSEM-AND4^tETO^ THE COQ R^ 

DINATED DRIVE TRAIN CONTROL OF A MOTOR VEHICLE 



(54) Bezeichnung: COMPUTERSYSTEM UND VERFAHREN ZUR STEUERUNG, INSBESONDERE ZUR KOORDINIERTEN 
ANTRIEBSSTRANGSTEUERUNG EINES KRAFTFAHZEUGES 



Plug-In 



Plug-In 



Plug-In 







: — n 




dd CARTF 


ONIC Layer 






i 


i k 
A 










ee Basis F 


: unfctionaiitpf 








A 

rr 


f . 2 


L 



AA...OPEN INTERFACES 
BB...ENCLOSED INTERFACES 
CC_PLUG-IN 
DD...CARTRONIC LAYER 
EE-. BASIS FUNCTIONALITY 

FF... OPERATING SYSTEM AND SPECIFIC SERVICES 



(5 7) Abstract: Th e invention concerns a prior art multi-layered module-like software design that has been further developed for 
^> vehicles andlilscfconcerns concrete procedures for the practical conversion thereof. To this end, the invention provides a computer 
^£ system having a software architecture (Fig. 4) containing concrete functional assignments and interfaces with exchangeable module- 
like plug-ins. With the aid of an inventive prioritization method, these plug-ins can be queried independent of the number and 
functionality of the requesting systems for flexibilizing. An inventive method for executing the drive train control of a motor vehicle 

Ois divided into 5 phases from the characterization of the environmental factors until the starting of the optimal operating point. This 
K method can also be used in an inventive computer system having an object-oriented software system. 

1^ [Fortsetzung auf der ndchsten Seite] 
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des and Abbreviations") am Anfang jeder reguldren Ausgabe der 
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(57) Zusammenfassung: Fiir Fahrzeuge wurde ein aus dem Stand der Technik bekannter mehrschichtiger modulartiger Softwa- 
reaufbau fortentwickelt und des Weiteren werden konkrete Vorgehensweisen zur praktischen Umsetzung angegeben. Hierzu wird 
erfindungsgemass ein Computersystem mit einer Softwarearchitektur (Fig. 4) angegeben, welche konkrete Funktionszuweisungen 
und Schnittstellen enthalt mit austauschbaren modulartigen Pluglns. Mit Hilfe eines erfindungsgemassen Priorisierungsverfahrens 
kQnnen diese Pluglns unabhangig von der Anzahl und Funktionsweise der anfordemden Systeme zur Flexibilisierung abgefragt wer- 
den. Ein erfindungsgemasses Verfahren zur Antriebsstrangsteuerung eines Kraftfahrzeuges ist in 5 Phasen von der Charakterisierung 
der Umwelteinfliisse bis zum Anfahren des optimalen Betriebspunktes eingeteilt. In einem erfindungsgemassen Computersystem 
mit objektorientiertem Softwaresystem kann dieses Verfahren auch eingesetzt werden. 
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5 

Computersvstem und Verfahren zur Steuerung, insbesondere zur koordinierten 
Antriebsstrangsteuerung eines Kraftfahrzeuges 

10 

Beschreibung 

Die Erfindung betrifft ein Computersvstem und ein Verfahren zur Steuerung, insbesondere zur 
15 koordinierten Antriebsstrangsteuerung eines Kraftfahrzeuges. 

In der Automobiltechnik wurde ursprttnglich die Elektronik nur in Form einzelner, elektronifizierter 
Komponenten eingesetzt, wobei diese Komponenten isoliert und unabhangig voneinander agierten. Daran 
anschliefiend wurden diese Komponenten zunehmend zu Systemen integriert. Beispiele hierfur sind 
2 0 elektronische Motorsteuerungssysteme, Bremsregelungssysteme oder Fahrerinforrnationssysteme. Derzeit 
ist ein Trend bin zur Vernetzung aller Fahrzeugsysteme untereinander und zunehmend auch mit der 
Fahrzeugumwelt zu beobachten. 

Dieses erkennbare Zusammenwachsen der Systeme bringt nun erhebliche technische und organisatorische 

2 5 Herausforderungen mit sich: 

neue Fahizeugfunktionen sind Mufig nur noch im Verbund unterschiedlicher Teilsysteme 
realisierbar und effektiv nutzbar, 

damit wird eine funktionale Integration von Teilsystemen auch unterschiedlicher Zulieferer 
erforderlich, 

3 0 die Wertigkeit und der Charakter von Fahrzeugen werden zunehmend durch komplexe 

Sofhvarefunktionen bestirnmt, 

die Beherrschung der wachsenden Systemkomplexitat wird fur Fahrzeughersteller und Zulieferer 
wettbewerbsentscheidend hinsichtlich Geschwindigkeit, Kosten und Qualitat 

3 5 Stand der Technik 
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Aus der DE 199 16 637 CI ist ein Verfahren zum Steuem des Antriebsstranges eines Kraftfahrzeuges und 
eine Antriebsstrangsteuerung eines Kraftfahrzeuges bekannt. Ziel ist es dabei auch fttr Kraftfahrzeuge mit 
einem automatischen Getriebe bei Betatigen der Betriebsbremse durch den Fahrer die VerzBgerung durch 
den Antriebsstrang des Kraftfahrzeuges zu untersttitzen. Eine Zentral-Steuereinheit bewertet einen 
5 Bremsmomentenwunsch oder FahrzeugverzSgerungswunsch des Fahrers, beispielsweise zusatzlich 
abhSngig von den Betriebsparametern Fahrertyp, Lastzustand und StraBenverhaitnisse (z. B. 
Wintennodus), der durch Betatigen des Bremspedals geauBert wird. Auf Basis dieses ermittelten 
Bremsmoments wird ein Motorschleppmomenten-Sollwert bestimmt. Die ttbersetzung des automatischen 
Getriebes wird abhangig vom Motorschleppmomenten-Sollwert anhand eines Riickschaltkennfeldes 
10 automatisch festgelegt Nachteiligerweise werden samtliche Vorgange von einer Zentral-Steuereinheit 
gesteuert, so dass eine Anpassung der Zentral-Steuereinheit an verschiedene Fahrzeugtypen oder der 
Einbau neuer Steuerungskomponenten nicht moglich ist. 

Aus der DE 199 40 703 CI ist ein Verfahren und eine Vorrichtung zur Motor- und Getriebesteuerung bei 
15 einem Kraftfahrzeug mit einem Verbrennungsmotor, der von einer Motorsteuerung gesteuert wird, und 
einem Stufenautomatikgetriebe, das von einer Getriebesteuerung gesteuert wird, bekannt. Dabei wird das 
Radantriebsmoment (Radmoment) auch bei einem Stufenautomatikgetriebe bei konstanter 
Fahrpedalstellung stetig (kontinuierlich) ttber der Fahrzeuggeschwindigkeit geandert Das Radmoment hat 
als Funktion der Fahrzeuggeschwindigkeit einen abnehmenden, hyperbelartigen Verlauf, bei dem 

2 0 ungeachtet der Schaltvorgange keine Unstetigkeit im Radmomentenverlauf auftritt. Aus einem vom Fahrer 

gewtinschten Radmoment wird von der Gesamtheit aus Momentenkoordinator, Motorsteuerung und 
Getriebesteuerung ein Soll-Motonnoment berechnet und im Rahmen der physikalischen Grenzen 
umgesetzt. AuBerhalb des Schaltvorganges des Stufenautomatikgetriebes wird dies dadurch erreicht, dass 
zumindest in Abhangigkeit von der Getriebetlbersetzung und dem vorgegebenen Getriebeabtriebsmoment 
25 eine auf die Ftlllung wirkende Momentenvorgabe und/oder eine auf die Zundung wirkende 
Momentenvorgabe berechnet werden. Damit soli ein bestimmtes Motormoment erreicht werden, welches 
unter Zwischenschaltung der bekannten Obersetzung gerade das vorgegebene Getriebeabtriebsmoment 
ergibt. Wahrend des Schaltvorganges des Stufenautomatikgetriebes erfolgt die Realisierung des 
Getriebeabtriebsmomentes im Wesentlichen Uber ein im Stufenautomatikgetriebe vorgesehenes 

3 0 Reibelement Entsprechend der fiir das Reibelement gewahlten StellgrSBe wird ein bestimmtes Moment 

libertragen. Daher wird die StellgrSBe wahrend des Schaltvorganges gerade so eingestellt, dass das 
gewQnschte Getriebeabtriebsmoment gemafi einer wahlbaren Obergangsfunktion erzielt wird. Nachteilig 
ist hierbei, dass das Radmoment ausschliefllich von der Fahrpedalstellung abhangt und keine anderen 
Faktoren, z. B. Fahrertyp oder Radschlupf, berlicksichtigt werden. Das Verfahren und die Vorrichtung 
35 sind nicht flexibel, weil diese in eine Motor- und Getriebesteuerung eines Fahrzeuges integriert sind, 
somit eine Obertragung auf andere Fahrzeugtypen und Steuergeratekonfigurationen nicht mOglich sind. 
Des Weiteren k5nnen auch nicht neue Steuerfunktionen integriert werden. 
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Aus der DE 198 38 333 Al der Anmelderin ist ein Computersystem mit wenigstens einem Prozessor und 
wenigstens einem Speicher zur Steuerung einer Antriebseinheit bekannt. Ziel ist es eine 
Steuerungsstruktur des Gesamtfahrzeuges anzugeben, mit deren Hilfe der Triebstrang und speziell die 
5 Antriebseinheit mit aufierhalb liegenden Komponenten verkntlpft werden kSnnen. Triebstrang und 
Antriebseinheit sind in einem Motormanagement in ein Gesamtfahrzeugkonzept eingebunden. Das 
Fahrzeug wird als Gesamtsystem, bestehend aus Funktionseinheiten, als eine erste Komporiente 
aufgefasst Das Gesamtsystem, bestehend aus Funktionseinheiten, wird in verschiedene, vorgebbare 
Komponenten, z. B. Fahrzeugbewegung und Antriebskoordinator, aufgeteilt Die Antriebseinheit wird 

10 dabei als eine Komponente vorgegeben. Die Antriebseinheit wird abhangig von den vorgegebenen 
Komponenten und/oder den an den SchnittsteUen zwischen den Komponenten ausgetauschten Daten 
gesteuert Durch diesen Systemverbund kfinnen einzelne Elemente oder Funktionseinheiten nicht mehr 
getrennt betrachtet werden, sondern eingebunden in das Gesamtkonzept Bei einer Antriebs- bzw. 
Motorsteuerung beispielsweise mttssen nicht nur Momenten- bzw. Leistungsanforderungen oder 

15 Drehzahlvorgaben der Fahrzeugbewegung, wie Lenkung, Bremse oder Fahrdynarnikregelung 
berucksichtigt werden, sondern auch die Leistungs- bzw. Momentenforderungen und/oder 
DrehzaWinfonnationen aller Nebenaggregate und Stellglieder. Daruber hinaus ergibt sich aber auch die 
Mdglichkeit, durch den Zugriff auf Daten und Informationen anderer Funktionseinheiten und Systeme, 
wie z, B. UmweltgrOBen, FahrzustandsgrSBen, FahrzeuggrfJBen und BenutzergrOBen, eine an die 

2 0 jeweiligen Gegebenheiten angepasste Antriebssteuerung durchzuftihren. Nachteilig ist hierbei jedoch, dass 

es nicht mdglich ist einzelne Funktionseinheiten modulartig auszutauschen, d. h. ein flexibler modulartiger 
Systemaufbau ist nicht vorhanden. Des Weiteren sind auch keine umfassenden Angaben zur konkreten 
Umsetzung der Zielvorgaben gemacht 

25 Aus der EP 0 883 510 Bl ist eine Antriebsstrangsteuerung fur ein Kraftfahrzeug bekannt, die eine 
Radmomentenberechnungsschaltung enthait, durch die die Stellung des Fahrpedals als ein vom Fahrer 
gewttnschtes Radmoment oder Getriebeausgangsmoment interpretiert und zum Berechnen von Sollwerten 
fur das von dem Antriebsstrang abzugebende Drehmoment verwendet wird, und die eine Steuerschaltung 
aufweist, die mit einem Fuzzy-System versehen ist, in dem das gewttnschte Radmoment zusammen mit 

3 0 Betriebsparametera des Kraftfahrzeugs und Umweltparametern ausgewertet wird, durch die anhand einer 

zentralen Fahrstrategie-Auswahlschaltung die Betriebsweise des Antriebsstrangs bei beliebiger Fahrweise 
des Fahrers und Fahrsituation des Kraftfahrzeugs an vorgegebene Kriterien angepasst wird, und die mit 
einer Motorleistungsstelleinheit verbunden ist, an die sie ein Ausgangssignal abgibt, durch welches das 
von den Radern auf die Fahrbahn abzugebende Soll-Raddrehmoment festgelegt wird. Es wird eine 
35 Strategie fur die Motorsteuerung, die Motorleistungsstelleinheit und die Getriebesteuerung zentral derart 
festgelegt, dass der AusstoB von Schadstoffen rninimiert wird. Die zentrale Strategie kann auch einen 
fahrleistungsorientierten Modus des Kraftfahrzeuges zum Ziel haben. Alle dezentralen Funktionseinheiten 
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werden bei dieser Strategic so eingestellt, dass eine bestmSgliche Beschleunigung und ein schnelles 
Ansprechen des Antriebes auf den Fahrerwunsch zur Verfligung stehen. Notwendig ist ein solcher Modus 
bei einer sportlichen Fahrweise und bei Bergauffahrt. Die Steuerung erfolgt tiber eine Steuerschaltung, 
wobei der Datenaustausch tlber eine schnelle serielle Buskommunikation, z. B. einen CAN-Bus, 
ausgeflihrt wird. 

Nachteilig ist hierbei, dass aufgrund der Gesamtkonfiguration nur eine sehr geringe Flexibilitat 
hinsichtlich unterschiedlicher Fahrzeug- und Steuergeratekonfigurationen und Wiederverwendbarkeit von 
entwickelten Softwarekomponenten besteht, weil sMmtliche Komponenten an die zentrale Steuerschaltung 
angepasst sind. 

In Kraftfahrzeugen werden ftir verschiedene Komponenten im Triebstrang, wie Motor und Getriebe, 
Schnittstellen zur Kommunikation vereinbart, tiber die Anforderungen Ubermittelt werden kdnnen, damit 
sie von der empfangenden Komponente ausgeflihrt werden (im Kraftfahrzeugbereich verbreitete 
technische Schnittstelle zur Steuergeratevernetzung ist beispielsweise der CAN-Bus). 

Neben dem Fahrpedal und dem Bremspedal gibt es viele weitere Anforderer, die Vorgaben an. den 
Antriebsstrang machen k6nnen. Typische Beispiele hierfiir sind Komfortsysteme wie der 
Fahrgeschwindigkeitsregler oder Sicherheitssysteme wie ASR und ESP. Dabei wird ein groBer Teil an 
Entwicklung und Rechenkapazitat nachteiligerweise dafiir aufgewendet, entsprechend der aktuellen 
Fahrsituation zu entscheiden, wann welches System tatsachlich aktiv den Arbeitspunkt des Triebstranges 
vorgeben oder beeinflussen darf. 

Es ist bekannt, aufsetzend auf einem Echtzeit-Betriebssystem als Standard-Betriebssystem, z. B. ERCOS 
oder OSEK bzw. OSEK/VDX, zur Steuerung von Betriebsablaufen eines Fahrzeugs eingebettete 
Softwarelflsungen einzusetzen. Dabei werden applikationsspezifische Funktionen, System- 
grundfunktionen, Kernfunktionen sowie die entsprechende Treibersoftware, also die spezifischen 
Basisfunktionen einerseits mit den unterschiedlichen Betriebsfunktionen und TeUbetriebsfunktionalitaten 
andererseits, welche das eigentliche Betriebsverhalten des Fahrzeugs bestimmen, verwobenu Notwendige 
bzw. gewunschte Veranderung von Funktionen oder das nachtragliche Einfttgen von Funktionen lassen bei 
solchermaBen verwobenen SoftwarelQsungen sehr komplexe Systemausbildungen, insbesondere der 
Schnittstellen, entstehen. 

Aus der DE 100 44 319 Al der Anmelderin ist bereits die abstrakte Idee bekannt durch die klare 
Trennung von Betriebs- und Basisfunktionen und die Einfuhrung einer Systemschicht bzw. 
Zwischenschicht mit offener SchnittsteUenfunktion eine Optimierung zu erzielen. Dabei wird von einem 
elektronischen System fiir ein Fahrzeug bzw. von einer Systemschicht des elektronischen Systems 
ausgegangen, wobei das elektronische System erste Komponenten zur Durchfuhrung von 



WO 2004/014700 



- 5 - 



PCTYDE2003/002541 



Steuerungsaufgaben bei Betriebsablaufen des Fahrzeuges und zweite Komponenten, welche ein 
Zusammenwirken der ersten Komponenten zur DurchfUhrung der Steuerungsaufgaben koordinieren, 
umfasst. Die ersten Komponenten fUhren dabei die Steuerungsaufgaben durch Verwendung von 
Betriebsfunktionen und Basisfunktionen aus. Vorteilhafterweise wird das System derart aufgebaut, dass 
Basisfunktionen und Betriebsfunktionen bzw. Tenbetriebsfunktionalitaten (als Betriebsteilmodule oder 
Plug-Ins bezeichnet) klar voneinander getrennt werden, wobei die Basisfunktionen in einer Basisschicht 
zusammengefasst sind. ZweckmSBigerweise wird dann die Systemschicht auf der Basisschicht, welche die 
Basisfunktionen enthalt, aufgesetzt. Die Systemschicht bzw. Zwischenschicht enthalt dabei wenigstens 
zwei der zweiten Komponenten, welche das Zusammenwirken der Steuerungskomponenten koordinieren. 
Dabei ist in bzw. bei der Systemschicht wenigstens eine offene Schnittstelle zu den Betriebsfunktionen 
vorgesehen, wodurch die Systemschicht die Basisfunktionen mit beliebigen Betriebsfunktionen derart 
verbindet, dass die Betriebsfunktionen modular eingebunden und/oder verwendet bzw. modular an das 
elektronische System angebunden werden k6nnen. Damit werden die Betriebsfunktionen bzw. die 
Betriebsteilmodule modular einbindbar in das elektronische System, wieder verwendbar und jederzeit 
austauschbar bzw. verSnderbar. Durch die Systemschicht wird eine definierte Schnittstelle festgelegt, um 
im Rahmen der Steuergerate-Software fUr beliebige Betriebsfunktionen eine Variantenbildung sowie 
Erweiterungen bzw. VerSnderungen der Funktionalitat, insbesondere durch Betriebsteilmodule, so 
genannte Plug-Ins, zu ennGglichen. In einer Ausgestaltung kann damit ein System, welches sich bereits in 
Serie bzw. im Einsatz oder Betrieb befindet, jederzeit weiterentwickelt, verandert und/oder durch 
Hinzufiigung neuer Betriebsfunktionen erweitert werden. Damit kBnnen sinnvollerweise 
Steuerungsaufgaben bzw. spezifische Leistungsmerkmale eines elektronischen Systems sehr flexibel und 
individuell entworfen, entwickelt bzw. implementiert werden. AuBerdem k6nnen zusatzlich die 
Oberwachungsfunktionen bezUglich der Betriebsfunktionen und/oder der Betriebsteilmodule in der 
Systemschicht eingebunden werden. Durch diese Modularisierung der Software- und 
Uberwachungsfonktionalitaten ergibt sich die MOglichkeit, beispielsweise von Dritten erstellte Software 
mit geringem Aufwand in das elektronische System einzubinden. Dies erlaubt auch, spezifische Varianten 
ausschlieBlich innerhalb der Betriebsfunktionen bzw. der Betriebsteilmodule darzustellen, wahrend die 
Systemschicht anwendungsunabhangig gestaltet werden kann. Nachteilig ist hierbei, dass lediglich 
formale Vorgaben gemacht werden und konkrete, inhaltliche Vorgehensweisen nicht angegeben sind. 

Vorteil der Erfindung 

Ausgehend vom geschilderten Stand der Technik soUen ein Coinputersystem und ein Verfahren zur 
Steuerung, insbesondere zur koordinierten Antriebsstrangsteuerung von Kraftfahrzeugen, geschaffen 
werden, welche tiber konkrete inhaltliche Vorgehensweisen verfilgen. 
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Die Erfindung schlagt ein Computersystem mit den Merkmalen der Patentansprttche 1 und 25 sowie ein 
Verfahren mit den Merkmalen der Patentansprttche 8, 12 und 19 vor. Vorteilhafte Ausgestaltungen der 
Erfindung sind Gegenstand der Unteransprttche und der nachfolgenden Beschreibimg. 

Dabei werden erfindungsgemSB insbesondere 

Anforderungen verschiedener Systeme in einheitlicher Art auf Basis von SystemfilhrungsgroBen 
(im Wesentlichen dem Getriebeausgangsmoment) zentral eingebracht, 

verschiedenste Verfahren zur ErmMung von geeigneten Betriebspunkten des Antriebsstranges 
eingebracht, 

die Anforderungen und Verfahren entsprechend der aktuellen Fahrsituation durch ein abstraktes 
Priorisierungsverfahren situationsgerecht priorisiert, so dass die richtige Anforderung 
berQcksichtigt und das optimale Verfahren zur B etriebspunktauswahl verwendet wird, 
die Anforderungen entsprechend der Triebstrangtopologie des betreffenden Fahrzeuges 
umgerechnet und Vorgaben an die Triebstrangkomponenten gemacht, wobei die Schnittstellen zu 
den Komponenten so abstrakt wie mSglich auf physikalischer Basis festgelegt werden, um 
Abhangigkeiten beispielsweise von verschiedenen Motortypen (Diesel und Benzin) 
weitestgehend auszuschalten, und 

die MOglichkeit geboten, die Ermittlung von Anforderungen und Verfahren zur Berechnung von 
optimalen Betriebspunkten in Plug-Ins zusammenzufassen, um so separierbare Systeme im Sinne 
von veraufierbaren Produkten zu schaffen. 

Zur funktionsfMhigen Umsetzung eines modulartigen Systemaufbaus ist es erforderlich eine 
Softwarearchitektur anzugeben, in der den einzelnen Elementen bzw. Komponenten klare Funktionen 
zugewiesen sind. Unter dem abstrakten Begriff der Architektur wird sowohl die Systematik der 
Strukturierung eines komplexen Systemverbundes als auch deren konkrete Umsetzung verstanden. Aus 
diesem Grund wird erfindungsgemafi ein Computersystem mit wenigstens einem Prozessor und 
wenigstens einem Speicher zur Steuerung, insbesondere zur Antriebsstrangsteuerung fur ein 
Kraftfahrzeug, angegeben, welches tlber eine entsprechende Softwarearchitektur verfttgt. Diese besteht 
aus den nachfolgenden Elementen bzw. Komponenten: ein "Operation System and Specific Services" mit 
Betriebssystem und spezifischen Diensten als Basis ftlr alle anderen Elemente und Anwendungen, einer 
"Basic Functionality" zur Umsetzung universeller Anforderungen, wobei Grundfunktionen eines 
Steuergerates, beispielsweise der Ansteuerung von Aktoren eines Verbrennungsmotors, in der Basic 
Functionality bewerkstelligt werden, einem "Layer" zur Koordinierung von Aufgaben fttr 
BasisfunktionaUtaten der Basic Functionality und zum Einbinden von Plug-Ins und wenigstens einem 
Plug-In zur Umsetzung von konkreten Aufgaben bzw. Funktionen, die ttber die Basisfunktionalitat der 
Basic Functionality hinausgehen und vom Layer koordiniert werden. 
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Dabei konnen vorteilhafterweise die Plug-Ins am Computersystem modulartig ausgetauscht werden, 
wodurch das Computersystem flexibel an unterschiedliche Hersteller- und Kundenwtinsche anpassbar ist 
und Funktionen einfach implementierbar sind. Dadurch konnen die in den Plug-Ins realisierten Kunden- 
Funktionen auf einfache und vorteilhafte Weise auf verschiedene Fahrzeugtypen oder unterschiedliche 
Motoren tibertragen werden, ohne diese selbst verSndern zu mttssen. Die Anpassung an eine verSnderte 
Fahrzeugkonfiguration wird durch Anpassungen beispielsweise in der Basic Functionality (z.B. Diesel- 
start Benzinmotor) vorgenommen. 

Des Weiteren kOnnen durch diesen modulhaften Aufbau auch neue Teilfunktionen einfach in das 
Computersystem eingefiigt werden. Dadurch ist beispielsweise auch ein Softwaresharing moglich. 

AuBerdem sind vorteilhafterweise in der Softwarearchitektur auch offene Schnittstellen (open interfaces), 
auf die von auBen zugegriffen werden kann, und geschlossene Schnittstellen (encapsulated interfaces), die 
nach aufien nicht freigegeben sind, integriert. 

Als Plug-Ins kommen zur Umsetzung von beispielsweise verschiedenen charakteristischen Eigenschaften 
von Fahrzeugen beispielsweise ein ACC Request (Adaptive Cruise Control Request) zur Anpassung der 
Geschwindigkeit oder des Abstandes des Fahrzeuges, ein Drivers Demand (comfort bzw. sport) zur 
Auslegung und Interpretation des Fahrpedals, Driveability zur Festlegung eines globalen 
Optmiienmgskriteriums, z. B. Fahrkomfort oder Sport, sowie Shift Strategy (comfort bzw. sport), die aus 
dem Sollwert fur das Drehmoment am Getriebeausgang und der Fahrzeuggeschwindigkeit den Sollwert 
fur die Getriebetibersetzung und das Motormoment bestimmt. 

Im Layer sind beispielsweise die Koordinatoren Vehicle Coordinator, Vehicle Motion Coordinator und 
Powertrain Coordinator integriert. Jeder Koordinator sollte mit den Plug-Ins kommunizieren konnen, d. h. 
tiber Schnittstellen mit den Plug-Ins verbunden sein. Des Weiteren sollte der Layer ttber Schnittstellen zur 
Kornmunikation mit der Basic Functionality verbunden sein, welche Basisfunktionen enthalt, die wie 
Sensoren oder Aktoren agieren, wobei z. B. das engine management als Momentensteller wirkt, das 
transmission management ein tJbersetzungsverhaltnis umsetzt, das brake management eine geforderte 
negative Sollbeschleunigung einstellt. 

Anforderungen verschiedener Systeme werden in einheitlicher Art auf Basis von SystemfuhrungsgroBen, 
z. B. Getriebeausgangsmoment, zentral eingebracht. Das erfindungsgemaBe Computersystem erlaubt es 
damit durch den einfachen Austausch oder das HinzufUgen von Funktionen, die in Plug-Ins enthalten sind, 
ein Kraftfahrzeug flexibel an verschiedene Anforderungen anpassen zu kSnnen. Dadurch konnen die 
Automobilhersteller eine Markendifferenzierung auf Softwarebasis eirifuhren, weil allein aufgrund 
unterschiedlicher Softwarekomponenten Fahrzeuge mit unterschiedlichen Eigenschaften zur Verfilgung 
stehen. Des Weiteren k6nnen auch die Kosten in erheblichem MaBe reduziert werden, weil zum Anpassen 
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an neue Funktionen nicht das gesamte Computersystem ausgetauscht werden muss, sondern lediglich 
durch den kostengttnstigen Austausch einzelner Plug-Ins die Eigenschaften verandert werden kCnnen. 

Um im beschriebenen erfindungsgemafien Computersystem auf einfache Weise die gewtinschte einfache 
5 Austauschbarkeit von Funktionen in den Plug-Ins erreichen zu kQnnen, ist es erforderlich, dass die iibrigen 
Komponenten der Softwarearchitektur unabhangig von der Anzahl und der Funktionsweise der Plug-Ins 
auf die Plug-Ins zugreifen kOnnen. Nur so k6nnen Plug-Ins beliebig ausgetauscht werden. Ein 
erfindungsgemaUes Priorisierungsverfahren von Informationsgebem, z. B. Plug-Ins, zur Steuerung, 
insbesondere zur koordinierten Antriebsstrangsteuerung fllr ein Kraftfahrzeug, setzt diese Zielsetzung um. 

1 0 Das Priorisierungsverfahren ist beispielsweise auch im eben genannten Computersystem einsetzbar. In den 
Plug-Ins bzw. Anforderern ist in Abhangigkeit von der aktuellen Fahrsituation ein Anforderungswunsch 
enthalten, wobei jedoch nicht bei jeder besthnmten Fahrsituation im entsprechenden Plug-In oder 
Anforderer auch ein Anforderungswunsch enthalten sein muss. Die Anforderer oder Plug-Ins werden nach 
dem Grad ihrer Prioritat aufsteigend oder abfallend sortiert, wobei diese Prioritat in Abhangigkeit von 

15 globalen Opthiiierungskriterien bestimmt wird, beispielsweise einer Okoabstimmung, Sportabstimmung 
oder einer Wintererkennung. In dieser entsprechend sortierten Liste mit Anforderern oder Plug-Ins werden 
die einzelnen Anforderer sequentiell beginnend mit dem Anforderer mit der hflchsten Prioritat 
abgearbeitet, dh.es wird abgefragt, ob ein Anforderungswunsch im Anforderer bzw. im Plug-In vorliegt. 
Sobald ein Anforderer einen Anforderungswunsch enthalt, wird das Abarbeiten abgebrochen, und der in 

2 0 diesem Anforderer enthaltene Anforderungswunsch ausgewShlt, voizugsweise gespeichert und weiter- 

geleitet. Jeder Anforderer in den sortierten Listen kann durch eine Identitat (ID), vorzugsweise als Zahl, 
und der Position in der Liste eindeutig gekennzeichnet sein. 

In einem weiteren erfindungsgemafien Priorisierungsverfahren von Informationsgebern, z. B. Plug-Ins, 
25 werden in einer Liste mit Anforderern bzw. Plug-Ins alle Anforderer in beliebiger Reihenfolge 
abgearbeitet, wobei diese Liste nicht nach Priorit&ten sortiert ist und das Abarbeiten hier beispielsweise 
auch sequentiell erfolgen kann. Daran anschliefiend wird der Anforderungswunsch in der Liste der 
Anforderer mit dem maximalen (minimalen) Anforderungswunsch oder der durchschnittliche 
Anforderungswunsch der Anforderer ermittelt Dieser maximale (minimale) Anforderungswunsch wird 

3 o anschliefiend gespeichert und weitergeleitet. 

Zur Ermittlung des maximalen (minimalen) Anforderungswunsches wird im Allgemeinen das nachfolgend 
beschriebene Schema verwendet. Die in der nicht sortierten Liste enthaltenen Anforderer bzw. Plug-Ins 
werden in beliebiger Reihenfolge abgefragt Der erste abgefragte Anforderungswunsch, der von einem 
35 einen Anforderungswunsch enthaltenden Plug-In stammt, wird zunachst zwischengespeichert. Jeder 
weitere abgefragte Anforderungswunsch wird mit dem zwischengespeicherten Anforderungswunsch 
verglichen, ob er grflfier (kleiner) ist als der zwischengespeicherte Anforderungswunsch. Falls ein abge- 
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fragter Airforderungswunsch gr6Ber (kleiner) ist als der zwischengespeicherte Anforderungswunsch, wird 
dieser abgefragte Anforderungswunsch zwischengespeichert und der vorhergehende Anforderungswunsch 
gelOscht, d. h. der bisher gespeicherte Wert wird vom aktuell abgefragten Wert tlberschrieben, wobei 
andemfalls keine Speicherung erfolgt, d. h. der bisher zwischengespeicherte Anforderungswunsch 
5 gespeichert bleibt Nach der Abfrage aller Anforderer ist der maximale (minimale) Anforderungswunsch 
zwischengespeichert und kann weitergeleitet werden. 

Hierbei kann in einer Variante bei bestimmten Anforderern, z. B. Anforderern, die Motor und Bremse 
ansteuern, mit einem bestimmten Anforderungswunsch, z. B. einem BremseingrifF, der minimale 
10 (maximale) Anforderungswunsch, z. B. der minimale Vortriebswunsch, ausgewahlt werden und 
andemfalls der maximale (minknale) Anforderungswunsch. 

In einer weiteren Variante des eben beschriebenen Priorisierungsverfahrens nach maximaler (minimaler) 
Auswahl ist es auch mOglich, dass einzehie Anforderer bzw. Plug-Ins bewirken, dass bestimmte andere 
15 Anforderer bei der Ermittlung des maximalen (minimalen) Anforderungswunsches nicht berucksichtigt 
werden. Beispielsweise kann ein Anforderer-Fahrpedal bewirken, dass alle anderen Anforderer, die eine 
Bremsung/V erzogerung bewirken, nicht berttcksichtigt werden. 

Jeder Anforderer bzw. ein Plug-In ist durch eine Identitat (ID), vorzugsweise eine Zahl, fur das 

2 0 Abarbeiten eindeutig gekennzeichnet. Das bedeutet, dass die Position in der Liste nicht von Bedeutung ist. 

Auch bei diesem Priorisierungsverfahren gibt es verschiedene Listen zum Anpassen an globale 
Optimierungskriterien, z. B. Okoabstimmung, Sportabstimmung oder Wintererkennung, wobei jedoch hier 
nur relevant ist, welche Anforderer in der Liste stehen. 

25 Beide eben beschriebenen Priorisierungsverfahren k6nnen auch miteinander kombiniert werden, wobei 
vorzugsweise das erstbeschriebene Priorisierungsverfahren zuerst eingesetzt wird und, falls dieses kein 
Ergebnis liefert, das zweite Priorisierungsverfahren angewendet wird. Das erste Priorisierungsverfahren 
liefert keinen Anforderungswunsch, falls in der entsprechenden Liste in keinem der Anforderer bzw. Plug- 
Ins ein Anforderungswunsch enthalten ist 

30 

Zur koordinierten Antriebsstrangsteuerung eines Kraftfahrzeuges ist es erforderlich, den komplizierten 
Prozess dieser Steuerung in einzelne Verfahrensschritte aufzuteilen, welche von einem entsprechenden 
Computersystem bzw. der Software umgesetzt werden kflnnen. Ein erfindungsgemaBes Verfahren zur 
koordinierten Antriebsstrangsteuerung eines Kraftfahrzeuges verfiigt im Wesentlichen tiber die 

3 5 nachfolgenden Schritte bzw. Phasen: 



1 . Charakterisierung der Umwelteinfltisse, 
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2. Festlegen eines globalen Optimierungskriteriums, z. B. sportlich, Okonomisch oder 
verschleiBschonend, 

3. Fahrerwimschmterpretation, 

4. Bestimmung des optimalen Betriebspunktes und 

5 . Anfahren des optimalen Betriebspunktes. 

Zur Charakterisierung des Umwelteinflusses im 1. Schritt werden aktuelle Umweltdaten aufbereitet mid 
ggf. typisiert, z. B. FahrzeuggrSfien (Geschwindigkeit, Querbeschleunigung), Triebstrangzustand 
(Kraftschluss und Schub/Zug), Fahrertyperkennung (sportlich oder dkonomisch durch Ableiten aus dem 
Fahrverhalten) und Fahrsituationserkennung (Berg, Kurve, Winter, Stadt, Autobahn). Im 2. Schritt wird 
ein globales Opminerungskriterium festgelegt Bei der Fahreiwunschinterpretation als 3. Verfahrensschritt 
wird eine Vorgabe fUr die Langsbewegung des Fahrzeuges beispielsweise aus der Fahrpedalinterpretation 
nach BeschleunigungA^erzOgerung und/oder den Vorgaben eines Fahrgeschwindigkeitsreglers oder ACCs 
abgeleitet, wobei eine SystemfulmingsgrdBe Getriebeausgangsmoment in eine Gr6Be 
Getriebeausgangsmoment fur den Antriebsstrang und eine Grofie Fahrzeugverzflgerung fur die Bremse 
aufgeteilt wird. Zur Bestimmung des optimalen Betriebspunktes im 4. Verfahrensschritt fUr ein 
Getriebeausgangsmoment wird ein bestimmtes Motonnoment und eine Getriebettbersetzung ermittelt. Das 
Anfahren des optimalen Betriebspunktes im 5. und letzten Verfahrensschritt wird innerhalb einer 
bestimmten Zeit durchgefilhrt, d h. das Anfahren erfolgt nicht abrupt oder maglichst schnell, sondern 
wird an bestimmte Kriterien, beispielsweise der Fahrbarkeit, Komfort, Sicherheit und dem 
Aggregateschutz angepasst. In diesen Phasen werden vorzugsweise die einzelnen Aufgaben der Phasen 
bzw. Schritte von Koordinatoren in einem Layer eines erfindungsgemaBen Computersystems bearbeitet. 
Die Inhalte der Phasen werden von den Plug-Ins ttber Schnittstellen tlbermittelt bzw. zur VerfUgung 
gestellt, wobei vorzugsweise die Auswahl der Plug-Ins nach einem der oben beschriebenen 
erfindungsgemaBen Priorisierungsverfahren erfolgt. 

Zur SchafiEung eines Computersystems zur Steuerung ist es zweckmaBig tiber ein objektorientiertes 
Softwaresystem zu verfilgen. Ein objektorientiertes Softwaresystem ist dahingehend strukturiert, dass die 
Software einzelnen Teilen bzw. Komponenten des zu steuernden Gegenstandes oder ZustandsgrOBen bzw. 
auch Aufgaben zugeordnet wird. In einem Kraftfahrzeug sind das beispielsweise das Fahrzeug, die 
Fahrzeugbewegung, der Motor, das Getriebe oder der Fahrertyp sowie die FahrzeuggrSBe. Das 
erfindungsgemaBe Computersystem mit wenigstens einem Prozessor/Speicher mit objektorientiertem 
Softwaresystem besteht im Wesentlichen aus den nachfolgenden objektorientierten Komponenten: 
Fahrzeugbewegung (Vehicle Motion, VM), Antriebsstrang (Powertrain, PT), Fahizeugkoordinator 
(Vehicle Coordinator, VC), Infogebern, beispielsweise UmweltgrOBen (Environment Data, ED), 
FahrzustandsgrfJflen (Driving Condition Data, DD), FahrzeuggrOBen (Vehicle Data, VD) und 
BenutzergrCBen (User Data, UD). In Infogebern werden aktuelle ZustandsgrSBen gespeichert Diese 
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objektorientierten Komponenten sind mit Schnittstellen nach auBen und innen (Interface In and Out) und 
einem Kriterienkoordinator (Criteria Coordinator, CC) zur Abfrage von Plug-Ins zur Komtnunikation mit 
Schnittstellen verbunden. Die Komponente Fahrzeugbewegung weist z. B. noch die Komponenten 
Traktions- und Fahrstabilitatssysteme (ESP), Fahrzeugbewegungskoordinator (Vehicle Motion 
Coordinator, VMC) und Vortrieb/Bremsen (Propulsion/Brake, PrB) auf. Diese Komponente Vor- 
trieb/Bremse weist z. B. noch die Komponenten Vortrieb (Propulsion System, PrSy), Bremssystem (Brake 
System, BrSy) und einen Vortriebs- und Bremskoordinator (Propulsion and Brakes Coordinator, PrBC) 
mit einer Komponente Beschleunigungsaufteiler (Acceleration Request Manager, AccRM) auf. Der 
Beschleunigungsaufteiler entscheidet bei einer negativen Beschleunigung (VerzOgerung) welcher Anteil 
vom Motor und welcher Anteil von der Bremse iibernommen wird. Die Komponente Antriebsstrang weist 
beispielsweise die Komponenten Antriebsstrangkoordinator (Powertrain Coordinator, PTC), Motor 
(Engine, Eng), Getriebe (Transmission, Tra) und den Infogeber Triebstrangzustandsgr5J3en (Powertrain 
Data, PD) auf. Der Kriterienkoordinator kann mit einer Anwendungsschnittstelle (Application 
Programming Interface, API) kommunizieren. Damit wird erfindungsgemaB ein objektorientiertes 
Softwaresystem zur Verftlgung gestellt, welches optimal an einen modulartigen Systemaufbau angepasst 
ist. 

In einer weiteren Ausgestaltung wird das oben beschriebene erfindungsgemaBe Verfahren mit 5 Phasen 
mit dem erfindungsgemaBen Computersystem mit objektorientiertem Softwaresystem umgesetzt. Es weist 
20 die nachfolgenden Schritte auf: 

Zur Charakterisierung der Umwelteinfmsse werden die aktuellen Umweltdaten bzw. 
ZustandsgrdBen den Infogebern zugewiesen, worauf alle anderen Komponenten zugreifen 
konnen, ausgenommen die TriebzustandsgrSBen, worauf nur der Antriebsstrang zugreifen kann. 
Im 2. Verfahrensschritt wird vom Fahrzeugkoordinator das Festlegen eines globalen 
25 Optimierungskriteriums gesteuert, welcher Vorschlage tlber den Kriterienkoordinator von 

ausgewahlten Plug-Ins abfragt. 

Im nachsten Verfahrensschritt wird vom Vortriebs- und Bremskoordinator die 
Fahrwunschinterpretation gesteuert, welche in Zusammenarbeit mit ausgewahlten Plug-Ins tlber 
den Kriterienkoordinator die Vorgaben fUr Bremse und Antriebsstrang ermittelt, wobei 

30 vorzugsweise der Fahrzeugsbewegungskoordinator diese Vorgaben mit den Traktions- und 

Fahrstabilitatssystem koordiniert mid diese Vorgaben an den Triebstrang bzw. das Bremssystem 
weitergibt, wobei tlber die Anwendungsschnittstelle beispielsweise eine Fahrbeschleumgung in 
ein Getriebeausgangsmoment umgerechnet wird und an den Antriebsstrang weitergeleitet wird. 
Im 4. Verfahrensschritt werden vom Antriebsstrangkoordinator zum Bestimmen des optimalen 

35 Betriebspunktes liber den Kriterienkoordinator Plug-Ins ausgewahlt und der 

Antriebsstrangkoordinator kommuniziert mit den Plug-Ins tlber den Kriterienkoordinator. 



10 
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Im 5. und letzten Schritt wird auf Basis der gleichen Vorgehensweise das Anfahren - damit ist 
der tJbergang vom aktuellen zum neuen Betriebspunkt gemeint - des neu gewahlten 
Betriebspunktes bestimmt 

Voizugsweise erfolgt bei diesem Verfahren die Auswahl der Plug-Ins mit einem der oben beschriebenen 
erfindungsgemaBen Priorisierungsverfahren. Dieses Verfahren gestattet somit mit Hilfe des 
objektorientierten Sofhvaresystems das erfindungsgemSBe Verfahren zur Steuerung eines Fahrzeuges 
auszufuhren. 

Teil der Erfindung sind auch die Computerprogramme mit Programmcodemitteln oder 
Computerprogrammprodukte mit Programmcodemitteln, die auf einem lesbaren Datentrager gespeichert 
sind, urn eines der erfindungsgemaBen Verfahren durchzufuhren, sofern das Computerprogramm auf 
einem Computer oder einer entsprechenden Recheneinheit ausgefuhrt wird. 

Zeichnungen 

Nachfolgend wird die Erfindung beispielhaft beschrieben. Dabei zeigem 

Fig. 1: ein Schema eines "intelligenten" Fahrzeuges der Zukunft, 

Fig. 2: einen schematisierten Entwicklungsprozess eines modulartigen Systemaufbaus, 

Fig. 3 : eine an der Fahrzeugtopologie ausgerichtete strukturierte Funktionsarchitektur, 

Fig. 4: eine schematisierte Obersicht auf eine erfindungsgemafie Softwarearchitektur des 



modulartigen Systemaufbaus, 



Fig. 5: 



eine schematisierte beispielhafte Konkretisierungsfonn der erfindungsgemaBen System- 
architektur des modulartigen Systemaufbaus, 



Fig. 6: 



eine schematisierte Ansicht der symbolischen Ausstattung eines Kraftfahrzeuges als 
Versuchstrager, 



Fig. 7: 



eine erfindungsgemaBe Softwarearchitektur mit Plug-In-Design in einer 
Schichtenansicht, 



Fig. 8: 



einen erfindungsgemaBen schematisierten inneren Aufbau eines Vehicle Motion 
Coordinators aus Fig. 7, 
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Fig. 9: eine graiische Darstellung einer erfindungsgemaBen linearen Priorisierung (erste Stufe) 

und einer erfindungsgemaBen Maximal-Auswahl (zweite Stufe), 

Fig. 10: ein erfindungsgemaBes Ablaufschema eines Priorisienmgsverfahrens als Kombination 

aus linearer Priorisierung (erste Stufe) und Maximal-Auswahl (zweite Stufe), 

Fig. 11: ein erfindungsgemaBes Verfahren zur koordinierten Antriebsstrangsteuerung in einer 

Darstellung zwischen Plug-Ins und Triebstrangkomponenten, 

Fig. 12: eine erfindungsgemafie Softwarestruktur fiir das erfindungsgemSBe Verfahren zur 

koordinierten Antriebsstrangsteuerung, 

Fig. 13: ein erfindungsgemaBes objektorientiertes Softwaresystem zur koordinierten Antriebs- 

strangsteuerung, 

Fig. 14: eine schematisierte Darstellung der Phasen des erfindungsgemaBen Verfahrens zur 

koordinierten Antriebssteuerung, 

Fig. 15: ein Softwaresystem gemaB Fig. 13 bei der Auswahl des Optimienmgskriteriums, 

Fig. 16: einen beispielhaften Priorisierungsablauf entsprechend Fig. 15 zur Auswahl des 

Optimierungskriteriums durch den Fahrzeugjcoordinator, 

Fig. 17: eine schematisierte Strukturierung gemaB Fig. 13 bei der Fahrwunschinterpretation, 

Fig. 18: einen beispielhaften Priorisierungsablauf analog Fig. 16 bei der 

Fahrwunschinterpretation, 

Fig. 19: eine beispielhafte Anforderung eines Plug-Ins, 

Fig. 20: eine schematisierte Strukturierung gemaB Fig. 13 zur Bestimmung des optimalen 

Betriebspunktes, 

Fig. 21: einen beispielhaften Priorisierungsablauf entsprechend Fig. 20 zur Bestimmung des 

optimalen Betriebspunktes, 
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Fig. 22: Eine schematisierte Strukturierung gemaB Fig. 13 zum Anfahren des optimalen 

Betriebspunktes, 

Fig. 23: einen beispielhaften Priorisierungsablauf entsprechend Fig. 22 zum Anfahren des 

5 optimalen Betriebspunktes und 

Fig. 24: eine schematisierte Strukturierung gemaB Fig. 13 bei der Benutzung einzelner Plug-Ins 

von verschiedenen Schnittstellen. 

1 0 Bevorzugte Ausftihrungsform 

Ein modulartiger Systemaufbau (auch unter Cartronic des Unternehmens Bosch bekannt) fUr alle 

Steuerungs- und Regelungsaufgaben im Fahrzeug ist eine offene Systemarchitektur. 

Die dem modularen Systemaufbau zugrunde liegende Vision gliedert das intelligente Fahrzeug der 

15 Zukunft in drei wesentliche Elemente, siehe Fig. 1 : 

Intelligente Sensoren erfassen alle fur den Fahrzeugbetrieb wichtigen Informationen. Hierzu 
gehdren z. B. Sensoren zur Erfassung von Bewegungsdaten wie Geschwindigkeit, 
Beschleunigung und Drehrate, Sensoren fur fahrzeuginterne GrOflen wie Temperaturen und 
Driicke und zukunftig auch vermehrt Sensoren zur Erfassung des Fahrzeugumfelds (z. B. 

20 Ultraschall, Radar, Video). 

Intelligente Aktoren setzen die erforderlichen Stellbefehle sicher und zuverlassig urn. 
Intelligente, elektronisch gesteuerte Aktoren sind z. B. der Antriebsstrang, bestehend aus 
Verbrennungsmotor und Getriebe zur Erzeugung des Vortriebsmoments, elektronisch geregelte 
Bremssysteme zur definierten VerzOgerung und Stabilisierung des Fahrzeugs und elektronisch 

25 geregelte Lenksysteme fUr eine sichere und feinfdhlige Spurflihrung. Diese Eingrifife werden 

kUnftig vermehrt "by wire" elektronisch gesteuert und tlberwacht erfolgen. 
Eine Mensch-Maschine-Schnittstelle (Human-Machine-Interface, HMT) gibt dem Fahrer die fur 
ihn in der jeweiligen Fahrsituation relevanten mfonnationen und erlaubt die sichere und 
komfortable Bedienung des Fahrzeugs tiber die Bedienelemente des Cockpits. 



30 



Die heutigen Fahrzeuge sind in der Regel durch "gewachsene" Elektronik-Stnikturen mit einer Vielzahl 
isolierter und autarker Einzelfunktionen und Steuergerate gekennzeichnet. Die Entwicklung ist damit 
meist auf eine Optirnierung der isolierten Einzelfimktionen und Subsysteme begrenzt, die Optimierung des 
Gesamtsystems gestaltet sich schwierig. 



35 



Zur Realisierung der Vision vernetzter Systeme im Fahrzeug wird daher eine durchgSngige, konsistente, 
modulare und offene Systemarchitektur erforderlich. Ziel der Systemarchitektur ist die nahtlose 
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Integration aller Teilsysteme zur effizienteren Darstellung tlbergeordneter Fahrzeugfunktionen, welche ein 
Zusammenwirken mehrerer Teilsysteme erforderiich machen. Weitere Ziele sind Flexibility hinsichtlich 
unterschiedlicher Fahrzeug- und Steuergeratekonfigurationen, einfachere Implementierung kunden- 
spezifischer Funktionen, sowie hohe Funktionssicherheit und Wiederverwendbarkeit von entwickelten 
5 Softwarekomponenten. 

Unter dem abstrakten Begriff "Architektur" soil im Folgenden sowohl die Systematik der Strukturierung 
des komplexen Systemverbundes als auch deren konkrete Umsetzung verstanden werden. Zur 
Beschreibung der "Architektur" lassen sich unterschiedliche "Sichten" unterscheiden, die jeweils durch 
10 eigene Beschreibungen (im Sinne unterschiedlich abstrakter bis konkreter Modelle) abgebildet werden, 
welche in den einzelnen Stufen eines Entwicklungsprozesses erzeugt und umgesetzt werden, siehe Fig. 2. 

Grundlage der Systemarchitektur des modulartigen Systemaufbaus ist eine an der Fahrzeugtopologie 
ausgerichtete, hierarchisch klar strukturierte Funktionsarchitektur, siehe Fig. 3. Die Funktionsarchitektur 
15 beschreibt Ordnung und Zusammenhang von logisch-modularen Funktionskomponenten: ihren Aufgaben, 
ihren Schnittstellen, sowie ihren Wechselwirkungen untereinander. WesentHche Elemente der 
Funktionsarchitektur sind Domanen, (Sub-)Systeme, funktionale Komponenten und Kommunikations- 
beziehungen. Das resultierende abstrakte Modell ist noch unabhangig von einer Implementierung mit 
einer speziellen Hardwaretopologie. 

20 

Die Funktionsarchitektur unterteilt das Fahrzeug in unterschiedliche "Domanen": Fahrzeugbewegung 
(Powertrain), Antrieb (Vehicle Motion), Karosserie und Innenraum (Body and Interior), elektrische 
Energieversorgung (Electrical Supply System), thermische Energieversorgung (Thermal Supply System) 
usw. Innerhalb jeder DomSne werden unterschiedliche Subsysteme identifiziert, die aus "fiinktionalen 
25 Komponenten" bestehen, welche tiber Kommunikationsbeziehungen miteinander in Wechselwirkungen 
stehen. Der Begriff "Komponente" meint dabei nicht zwangslSufig die physikalische Einheit im Sinne* 
eines Bauteils, sondern eine Funktionseinheit, die sich ggf. als Subsystem in weitere funktionale 
Unterkomponenten zerlegen lasst 

3 0 Jedes der Subsysteme koordiniert seine Unterkomponenten selbst, die Koordination zwischen 
Teilsystemen Ubernehmen spezielle Funktionskonq)onenten, die als Koordinatoren bezeichnet werden. 

Bei den Kommunikationsbeziehungen werden die vier Grundtypen AuftrSge, Anforderungen, 
RUckmeldungen, und Abtxagen unterschieden. Eine Anforderung ist der Wunsch zur Ausfiihrung einer 
35 Aufgabe, wahrend ein Auftrag mit der Pflicht zur Ausfiihrung verbunden ist. Wahrend ggf. mehrere 
unterschiedliche funktionale Komponenten ahnliche und auch konfliktSre Anforderungen stellen kGnnen 
(beispielsweise unterschiedhche Verbraucher ein Antriebsmoment eines Motors), erfolgt die 
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Auftragserteilung durch genau einen Auftraggeber (z. B. einen Antriebsstraagkoordinator) an genau einen 
Auftragnehmer (z. B. den Verbrennungsmotor). Der Auftragnehmer gibt dem Auftraggeber 
gegebenenfalls eine Ruckmeldung tlber die Ausfuhrung. 

5 Die Funktionsarchitektur kann grafisch oder auch durch UML-Modelle abgebildet werden. Unabhangig 
von der gewShlten Beschreibungsfonn liefern die zugrunde liegenden Stnikturierungsregeln insbesondere 
in der Phase der Systemanalyse eine konsistente Methode zur Beherrschung der Komplexitat, und 
erlauben die systematische Definition funktionaler Schnittstellen. 

10 Der nachste Schritt im EntwicMungsprozess besteht in der Umsetzung der Funktionsarchitektur in eine 
geeignete Softwarearchitektur. Die Softwarearchitektur beschreibt die Strukturen der Software des 
Systems, sie besteht aus Softwarekomponenten, die in sich in weitere Software-Unterkomponenten 
unterteilt werden konnen. Der Funktionsumfang einer Softwarekomponente muss im Allgemeinen nicht 
zwangslaufig mit einer funktionalen Komponente des modulartigen Systemaufbaus gleichgesetzt werden. 

15 Die fiinktionale Strukturierung von Komponenten des modulartigen Systemaufbaus unterstutzt aber ein 
objektbasiertes Softwaredesign. 

Fig. 4 zeigt eine produktorientierte, schematisierte Obersicht auf eine auf dem modulartigen Systemaufbau 
basierende erfindungsgemafie Softwarearchitektur. Vereinfacht lassen sich folgende Elemente 
2 0 unterscheiden: 



"Operation System and Specific Services" mit Betriebssystem und spezifischen Diensten als 
Basis ftir alle Anwendungen, die auf dem Steuergerat laufen sollen; 

"Basic Functionahty" bezeichnet Grundfunktionen des Steuergerats zur Umsetzung universeller 
25 Anforderungen (z. B. Ansteuerung der Aktoren eines Verbrennungsmotors). Die 

Basisfunktionalitaten werden aus der Funktionsarchitektur ermittelt und strukiuriert; 
"Layer": diese Softwarekomponente fiihrt die Koordinationsaufgaben fiir mehrere Basisfunktio- 
nalitaten durch und bindet Plug-Ins ein; 

"Plug-In": diese Softwarekomponenten setzen konkrete, separierbare Aufgaben urn, die tiber die 
3 0 Basisfunktionalitat hinausgehen und durch die Komponente Layer koordiniert werden. 



In dieser Aufteilung kOnnen offene und gekapselte Schnittstellen (open and encapsulated interfaces) unter- 
schieden werden. Gekapselte Schnittstellen sind nach auBen nicht freigegeben, wahrend auf offene 
Schnittstellen frei zugegriffen werden kann. Die Modularitat dieser Softwarearchitektur unterstutzt die 
3 5 Austauschbarkeit von Teilfunktionalitaten und ermoglicht damit ein Softwaresharing. 
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Ftir die Implementierung des Systemverbunds spielt die Aufteilung von Funktionen auf konkrete 
Steuergerate und die Abbildung von Kommunikationsbeziehungen auf eine Netzwerktopologie eine 
entscheidende Rolle. WShrend im traditionellen Ansatz "gewachsener" Systeme typischerweise im ersten 
Schritt die Aufteilung der Steuergerate und deren Vernetzung vorgegeben wurde und sich Funktions- und 
5 Softwarearchitektur an diesen Gegebenheiten ausrichten musste, unterstUtzt der modulartige 
Systemaufbau hier einen systematischen simultanen Entwicklungsprozess. 

Der modulartigen Systemaufbau erlaubt durch die zugrunde liegende Koordination verteilter Systeme eine 
flexible Systemrealisierung sowohl in dezentral verteilten als auch zentral konzentrierten 
10 Steuergerateaufteilungen. Auch hinsichtlich der Verwendung spezifischer Bussysteme und 
Kommunikations standards erlaubt der modulartige Systemaufbau durch Kapselung der damit 
verbundenen Schnittstellen eine hohe Flexibilitat 

Die je nach Marktsegment und Hersteller spezifisch unterschiedlichen Topologien werden daher vom 
15 modulartigen Systemaufbau mit einem hohen Wiederverwendungsgrad von Funktions- und 
Softwarekomponenten unterstQtzt. 

Wie die vorhergehenden AusfUhrungen gezeigt haben, bilden klar definierte, standardisierte Schnittstellen 
ein Kernelement fiir die Bewaltigung der Herausforderungen eines Systemverbundes. 

20 

Die Systemarchitektur unterstUtzt die Erarbeitung universeller Schnittstellen. Je nach Sicht lassen sich 
dabei unterschiedliche Konkretisierungsfonnenunterscheiden, siehe Fig. 5: 

Funktionale Schnittstellen (basic functional interface), die ausgehend von einer vereinfachten 
25 Form (Beispiel: die Momentenanforderung an den Verbrennungsmotor) in abstrakte 

Signalschnittstellen detailliert werden (Beispiel: die Detaillierung der Momentenanforderung in 
Form eines momentanen Solhnoments (torque request), einem langerfristigen Ftihrungsmoment 
(torque lead request), und z. B. weiteren Dynamik- und Statusinformationen (torque set time, 
characteristics), 

3 0 - konkrete Softwarescbnittstellen innerhalb eines SteuergerSts, wobei die funktionalen 

Schnittstellen durch softwaretechnische Anforderungen ergSnzt werden (Beispiel: die Codierung 
der Momentenanforderung in Form von Variablennamen, Datentypen, Skalierungen, 
AmpUtuden- und Zeitquantisierung fiir momentanes Sollmoment, Ftihrungsgrtffle, Dynamik- und 
Statusinformationen), 

35 - sowie konkrete Signalschnittstellen auf einem Bus zwischen Steuergeraten (Beispiel: die 

Codierung der Momentenanforderung in Form von Signalnamen, Datentypen, Skalierungen, 



WO 2004/014700 





PCT/DE2003/002541 



- 18 - 



Amplituden- und Zeitquantisierung sowie Busadressen fur momentanes Sollmoment, 
Ftihrungsmoment, Dynamik- und Statusinformationen). 

Ein wesentlicher Vorteil besteht darin, dass die unterschiedlichen SchnittsteUenformen transparent 
5 zugeordnet und ineinander ttberfuhrt werden kOnnen. Damit kann zum Zeitpunkt der Entwicklung einer 
Softwarefunktion eine weitgehende Unabhangigkeit der Software-Schnittstellen vom tatsachlichen 
Transportmechanismus der Information (innerhalb eines Steuergerats Oder tiber einen Bus) sichergestellt. 
werden. Durch Kapselung speziflscher Teilsystemeigenschaften lasst sich auBerdem sicherstellen, dass die 
Schnittsteilen unabhangig von der technischen Ausftflirungsform der verbundenen Teilsysteme sind. Ein 
10 Beispiel bildet die Momentenschnittstelle zum Verbrennungsmotor, welche universell sowohl fUr Benzin- 
als auch Dieselmotoren geeignet ist 

Diese Architektur untersttltzt die nahtlose funktionale Integration unterschiedlicher elektronischer 
Fahrzeugsysteme. Darttber hinaus erlaubt das Plug-In-Konzept die Tmplementierung von 
1 5 Sofrwaremodulen zur charakteristischen Auslegung des Fahrverhaltens. 

Fig. 6 zeigt symbolisch die Ausstattung eines Fahrzeugs. Die Motorsteuerung EMU (Engine Management 
Unit) ist mit den Sensoren und Aktuatoren des Motors sowie mit dem Sensor des Fahrpedahnoduls 
verbunden. Ferner verfugt das Fahrzeug tiber ein Bremsensteuergerat BMU (Brake Management Unit), 
2 0 eine elektronische Getriebesteuerung TMU (Transmission Management Unit) sowie ein ACC-SteuergerSt, 
welches die Signale des Radarsensors verarbeitet Ein CAN- (Controller Area Network) Bus verbindet die 
Steuergerate untereinander. 

Die Ausstattung erlaubt die flexible Konfiguration fur unterschiedliche Fahrzeugcharaktere, nachfolgend 
25 exemplarisch in zwei Auspragungen als "sportlich" und "komfortabel" bezeichnet. Ein Schalter im 
Fahrzeuginnenraum ermOglicht es dem Fahrer, zwischen diesen beiden Fahrzeugcharakteren 
umzuschalten. Im Unterschied zu herkdrnmlichen Implementierungen derartiger Fahraeugcharakteristiken, 
beruht die Unterscheidung nicht nur auf unterschiedlichen Parameter-Applikationen innerhalb der 
Einzelsysteme, es werden vielmehr auf einer ubergeordneten Ebene Sofrware- ,, Plug-In ,, -Funktionalitaten 
30 zur Anpassung des Gesamtsystemverhaltens herangezogen, welche tiber Schnittsteilen die jeweils 
hinsichtlich Software und Abstimmung unveranderten Einzelsysteme ansprechen. 

Um den Komfortcharakter beispielsweise einer Limousine der Premiumklasse darzustellen, wurden 
exemplarisch folgende Anforderungen gestellt 



Das Fahrzeug soli ein Adaptive Cruise Control (ACC) System erhalten. Dieses System ermOglicht eine 
Anpassung der Geschwindigkeit an eine Fahrervorgabe sowie des Abstandes an vorausfahrende 



35 



WO 2004/014700 




PCT/DE2003/002541 



Fahrzeuge, indem Antrieb und Bremse elektronisch angesteuert werden. ACC ist ein innovatives 
Ausstattungsmerkmal, das den Premixuncharakter unterstreicht und den Fahrkomfort erhflht 

Elektronische Bremseingriffe fur ACC und andere Langsregelsysteme (wie z. B. einem 
5 Fahrgeschwindigkeitsregler mit BremseingrifT) sollen ttber das BremssteuergerSt (BMU, Brake 
Management Unit) mOglich sein. 

Das Fahrzeug soli sich bei der Gasannahme "welch" anfiihlen, d. h. ein ruckartiges Anfahren soil 
vermieden werden. Ebenso sollen Lastwechsel "sanft" erfolgen, d. h. die Eigendynamik des Triebstranges 
10 soil ftir den Fahrer unter keinen Umstanden spfirbar sein. Die Getriebeschaltung soil auf einen eher 
okonomischen Betrieb ausgerichtet sein, d. h. der Motor soli vorrangig bei niedrigen Drehzahlen 
betrieben werden. 

Im sportlichen Fahrzeugcharakter wurden als oberstes Ziel der FahrspaB optimiert. Entsprechend dem 
15 vorgegebenen Fahrzeugcharakter sollten Getriebe- und Motorsteuerung wie folgt ausgelegt werden: 

Der Motor soli spontan Gas annehmen, d. h. die Fahrpedalinterpretation soil "scharf 1 appliziert sein. 
Lastwechsel sollen schnell erfolgen kdnnen, d. h. die DSmpfung zur Unterdrttckung der 
Triebstrangdynamik ist sekundSr bezUglich der Spontaneitat. Der Motorbetriebspunkt soli zu Gunsten 

2 0 hoher Drehzahlen ausgelegt sein, damit der Fahrer jederzeit tiber eine mdglichst hohe Leistungsreserve 

verfilgt 

Zur Demonstration der hoben Flexibilitat wird bei dieser Auslegung auf Einbindung des Komfortfeatures 
"ACC" verzichtet 

25 Fig. 7 zeigt die verwendete erfindungsgemaBe Softwarearchitektur zur Umsetzung mit Plug-In Design in 
der Schichtenansicht: 

Die oberste Schicht wird von sechs Plug-Ins gebildet, welche die charakteristischen Funktionen zur 
Umsetzung der Anforderungen an die zwei Fahrzeugcharaktere enthalten: 
ACC Request: 

3 0 ein Regelkreis sorgt fttr die Anpassung der Geschwindigkeit oder des Abstandes. Der Regler ist 

typischerweise Bestandteil der ACC-Steuerung und hat eine Beschleunigung als StellgrCBe. 
ACO-Request tibernimmt diese und speist sie als Anforderung in den Vehicle Motion 
Coordinator ein. 

Drivers Demand comfort bzw. sport (in Fig. 7 getrennt dargestellt): 
35 ein elektronisches Fahrpedal wird in dieser Komponente ausgewertet und als Vortriebsmoment 

am Getriebeausgang interpretiert. Diese Funktion hat starken EinfluB auf das Fahrverhalten und 
damit auf den Markencharakter. Das comfort Plug-In enthalt eine weiche Fahrpedal- 
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interpretation, wShrend die sportliche Variante scharf ausgelegt ist, d. h. ein hohes Drehmoment 
bei vergleichsweise kleinem Fahrpedalweg. Das berechnete Vortriebsmoment am 
Getriebeausgang wird tlber die Schnittstelle als Anforderung an den Vehicle Motion Coordinator 
gestellt 
Driveability: 

dient u. a. der Festlegung eines globalen Optimierungskriterinms, also in einem Fall 
"Fahrkomfort" und in dem anderen "Sport". Ein weiterer Bestandteil dieser Komponente sind die 
Komfortfunktionen zur Lastschlagfilterung, d. h. Anderungen im Sollmoment werden so 
gedampft, dass kein stSrendes Ruckeln oder Schwingungen im Triebstrang auftreten. Diese 
Gradientenbegrenzung verhindert die Erregung von Triebstrangschwingungen im Bereich der 
Eigenfrequenzen. "Ober eine Schnittstelle kann dem Vehicle Motion Coordinator ein minimaler 
und maximaler Gradient des Antriebssollmoments vorgegeben werden. DarHber hinaus wertet 
Driveabilty den Schalter aus, mit dem zwischen dem sportlichen und komfortablen 
Fahrzeugcharakter umgeschaltet werden kann. Als Alternative zu einem Schalter kOnnte hier 
ebenfalls eine Fahrertyperkennung realisiert werden. Der ausgewShlte Modus wird anschlieBend 
an den Vehicle Coordinator weitergeleitet. Ein weiteres Feature ermSglicht, bei Gangwechseln 
den Ruck durch gezielte Steuerung des Motormoments zu vermeiden, indem ein minimal und ein 
maximal einzuhaltendes Motormoment an Powertrain Coordinator tibergeben werden. 
Shift Strategy comfort bzw. sport (in Fig. 7 getrennt dargestellt): 

enthalt eine Rechenvorschrift, die aus dem Sollwert fiir das Drehmoment am Getriebeausgang 
und der Fahrzeuggeschwindigkeit den Sollwert fiir die Getriebetlbersetzung und das 
Motormoment bestimmt. Um die Vorgabe des Sollmoments zu erfUUen, ergibt sich bezttglich 
aktueller Geschwindigkeit ein Freiheitsgrad in der Wahl des tJbersetzungsverhaitnisses. Das 
Obersetzungsverhaltnis wird entweder zugunsten eines Okonomischen Motorbetriebspunktes 
(Shift-Strategy comfort) oder zugunsten einer hohen Leistungsreserve (Shift-Strategy sport) 
gewahlt. Sowohl der Sollwert ftir das Obersetzungsverhaltnis als auch fiir das Motormoment 
werden an den Coordinator Powertrain gesendet Dariiber hinaus ist eine Funktion zur 
UnterdrQckung von Pendelschaltungen enthalten. Ober die gemeinsame Schnittstelle werden dem 
Powertrain Coordinator ein minimal bzw. maximal zul&ssiger Gang vorgegeben, welche bei 
Schaltungen einzuhalten sind. 

Unterhalb der Plug-Ins befindet sich in Fig. 7 der Layer, welcher die Koordinatoren Vehicle Coordinator, 
Vehicle Motion Coordinator und Powertrain Coordinator umfaBt. Jeder Koordinator verfilgt tlber beliebig 
viele Ausfiihrungen einer klar definierten fixen Schnittstelle zur Kommunikation mit den Plug-Ins. Fiir 
jedes Plug-In, das mit einem Koordinator kommunizieren m5chte, stellt dieser eine weitere Ausmhrung 
seiner Schnittstelle zur VerfUgung. In diesem Fall ist z, B. Vehicle Motion Coordinator insgesamt mit drei 
Plug-Ins verbunden: ACC Request, Drivers Demand und Driveability. Die einheitlichen Schnittstellen 
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ermoglichen die Darstelltmg eines breiten Spektrums an Funktionalitat in den Plug-Ins. WShrend die 
Koordinatoren die Plug-Ins mit alien globalen Fahrzeugdaten versorgen, sind die Schnittstellen in 
iraigekehrter Richtung - also vom Plug-In zu den Koordinatoren - dagegen vergleichsweise schmalbandig. 
Haufig kommt es innerhalb eines Koordinators zu Konflikten zwischen konkurrierenden Anforderungen 
(z. B. gleichzeitiger Vortriebswunsch von ACC und ttber Fahrpedal). Diese kOnnen raithilfe eines 
flexiblen Priorisierungsverfahrens zu Gunsten einer vorgebbaren Strategic entscbieden werden. In einer 
applizierbaren Priorisierungstabelle wird festgelegt, welche Plug-Ins aufgerufen werden. Das Prinzip 
dieses Priorisierungsverfahrens wird nachfolgend am Beispiel des Vehicle Motion Coordinator 
verdeutlicht 

Mit der tiefer gelegenen Softwareschicht der Basic Functionality ist der Layer tlber Standard- 
Schnittstellen verbunden. Diese Basisfunktionen verhalten sich aus Sicht des Layers wie intelligente 
Sensoren oder Aktuatoren. Zum Beispiel fungiert die Komponente Engine Management als ein 
Momentensteller, Transmission Management setzt das befohlene Obersetzungsverhaltnis um, Brake 
Management stellt die geforderte Sollbeschleixnigung ein und ACC liefert die Daten aus Objekterkennung 
und ACC-Bedienteil. 

Fig. 8 zeigt den inneren Aufbau des Vehicle Motion Coordinators aus Fig. 7. Ober einheitliche 
Schnittstellen werden die Informationen der Plug-Ins in einen Puffer eingelesen. Die 
20 Schnittstelleninformation besteht jeweils aus der Identitat (ID), die jedes Plug-In eindeutig kennzeichnet, 
sowie einen Nutzanteil (values), welcher die Funktionalitat bestimmt. Zum Beispiel hat ACC Request die 
ID 7 und sendet eine BescMeunigungsanforderung (a), Drivers Demand sport (ID 12) sendet ein 
Vortriebsmoment am Getriebeausgang (trq) und Driveability (ID 19) eine obere und unter Grenze fttr den 
Gradienten des Vortriebsmoments am Getriebeausgang (trq). Ein geeignetes Priorisierungsverfahren 
25 (Priorization), in diesem Fall eine lineare Priorisierung, legt die Abarbeitungsreihenfolge (Operation 
Order) der Anforderungen aus den Plug-Ins fest und teiit das Ergebnis der ausflihrenden Instanz 
(Operation) mit Die Prioritaten kSnnen mr jede ID in einer Priorisierungstabelle bzw. -liste (calibratable 
Priorization table) appliziert werden. Zur Darstellung unterschiedlicher Fahrzeugcharaktere kOnnen 
gleichzeitig mehrere Priorisierungstabellen abgelegt sein, z. B. mr "Sport" und fOr "Comfort". In diesem 
3 0 Fall enthalt beispielsweise die Priorisierungstabelle flir "Comfort" lediglich den Aufruf des Plug-Ins 
Drivers Demand comfort (ID 23), wahrend z. B. das Plug-In Drivers Demand sport (ID 12) nicht 
aufgerufen wird. Umgekehrt enthalt die Priorisierungstabelle fiir einen sportlichen Fahrbetrieb nur einen 
Eintrag der Plug-Ins Drivers Demand sport (ID 12) und Driveability (ID 19), wobei ACC-Request (ID 7) 
gezielt nicht beriicksichtigt wird. Die Auswahl der Priorisierungstabelle wird von Vehicle Coordinator 
35 getroffen. Die ausfUhrende Einheit (Operation) ruft die Anforderungen der Plug-Ins nach Vorgabe der 
Operation Order auf und verarbeitet diese: 
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Im Ergebnis wird eine Sollbeschlennigung ermittelt, welche auf die SteUglieder Antrieb (Motor und 
Getriebe) oder Bremse verteilt wird. Im Fall einer Bremsung wird sie tiber die Schnittstelle zum Brake 
Management weitergeleitet Im Antriebsfall wird die Beschleunigung mithilfe der Zugkraftgleichung in 
ein Sollmoment am Getriebeausgang umgerechnet, anschlieBend kommt es zur Koordination mit der 
5 Anforderung aus Drivers Demand. In der Regel setzt sich die Anforderung mit dem grflBeren 
Drehmomentenwunsch durch. In Ausnahmef&llen (je nach Priorization table) kann es aber auch sinnvoll 
sein, dass zu Gtmsten der Beschleunigungsanforderung des ACC entschieden wird. Zum Beispiel erweist 
es sich als komfortabel, eine Bremsverz8gerung nicht schlagartig zu beenden, wenn eine aktive Bremsimg 
des ACC vorliegt und der Fahrer gleichzeitig Gas gibt, d. h. wenn der Fahrer iiberreitet Das resultierende 
10 Sollmoment am Getriebeausgang wird anschlieBend an den Vehicle Coordinator (siehe auch Fig. 7) 
weitergeleitet. 

Der Vehicle Coordinator leitet das Sollmoment an den Powertrain Coordinator (siehe auch Fig. 7) weiter 
und legt die Berechnungsreihenfolge aller Koordinatoren fest. Darttber hinaus sorgt er fur die Umsetzung 
15 der globalen Fahrstrategie. Diese wird von Driveability in Form eines globalen Optimierungskriteriums 
("Komfort" oder "Sport") entsprechend der Schalterstellung bestimmt und tiber die gemeinsame 
Schnittstelle gesendet Auf Grundlage des Optimierungskriteriums legt Vehicle Coordinator die zu 
verwendenden Priorisierungstabellen in den Koordinatoren fest 

2 0 Der Powertrain Coordinator setzt die Anforderung zur Realisierung eines Getriebeausgangmoments von 

Vehicle Coordinator urn. Ahnlich wie in Coordinator Vehicle Motion wird anhand eines 
Priorisienmgsverfahrens die Bearbeitungsreihenfolge der Anforderungen aus den Plug-Ins, Shift-Strategy 
comfort bzw. sport sowie Driveability bestimmt Je nach ausgewahlter Priorisierungstabelle wird nur eine 
der beiden Schaltstrategien tiber die ID aufgerufen. Transmission Management wird unter 
25 Berticksichtigung des minimal bzw. maximal zulassigen Gangs aus Shift-Strategy zur Umsetzung des 
Sollwerts beauftragt Bei einem Gangwechsel wird das Motormoment nach vorgegebener unterer und 
oberer Grenze aus Driveability an die Basisfunktion Engine ttbergeben. 

Alle Anforderungen an die Charaktere "sport" und "comfort" konnten mit insgesamt sechs Plug-Ins 

3 0 erfolgreich umgesetzt werden. Mit dem Schalter im Fahrzeuginnenraum kann wahrend der Fahrt zwischen 

beiden Modi umgeschaltet werden. Die Integration des ACC-Systems in der "comfort"-Auspragung 
erfolgte ohne Anderungen in dem Layer. Dies untermauert die Mfichtigkeit der Schnittstellen zu den Plug- 
Ins und erlaubt die zukQnftige Integration anderer Anwendungen wie z. B. einer situationsabhangigen 
Geschwindigkeitsbegrenzung oder Cruise Control mit Bremseingriff als Alternative zu ACC. Die 
35 standardisierten Schnittstellen der Layer mit den Basisfunktionen, wie z. B. Engine und Transmission, 
erm5glicht auBerdem eine Entkopplung der Fahrfunktionen von den Aggregaten: sie ermflglichen die 
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Verwendung der gleichen Fahrfunktionen fur unterschiedliche Motortypen (Otto- und Dieselmotoren) und 
unterschiedliche Getriebetypen (z. B. fiir Stufenautomatikgetriebe und CVT). 

Mit dem applizierbaren Priorisiemngsverfahren werden auch dynamische Wechsel zwischen 
5 unterschiedlichen Fahrverhaltensmodi mdglich, wenn dies - z. B. mit einer Fahrertyperkennung — 
gewttnscht wird. Im vorliegenden Beispiel demonstriert der Wechsel zwischen den Typen sport und 
comfort der Plug-Ins Drivers Demand und Shift-Strategy die Flexibilitat des Priorisierungsverfahrens fur 
die Austauschbarkeit ganzer Algorithmen. 

Im Gegensatz zu herkOmmlichen Systemen, die lediglich unterschiedliche Charakterisierung des 
10 Fahrzeugverhaltens durch Parameteranderung in isoUerten Teilsystemen erlauben, ermoghcht die 
erfindungsgemafie Systemarchitektur eine tief greifende, flexible Markencharakterisierung des 
Gesamtfahrzeugs durch Plug-Ins bei gleichzeitiger Wiederverwendung der zugrunde Hegenden Software. 

Es handelt sich urn eine abergreifende, offene Systemarchitektur fur alle Steuerungs- und 
15 Regelungsaufgaben im Kraftfahrzeug. Sie ist unabhangig vom Fahrzeugtyp und von der Steuergerate- 
Konfiguration. Sie beruht auf einer klar gegliederten, hierarchischen Funktionsarchitektur und modularen 
Software mit offenen, einheitlichen Schnittstellen in den beteiligten Steuergeraten. Damit k6nnen die 
Aufgaben flexibel auf einzelne Hardware-Komponenten des elektronischen Systems verteilt werden. Es 
lassen sich die immer komplexeren Fahrzeugsysteme leichter beherrschen. 

20 

Am Beispiel wurde gezeigt, dass eine flexible Markencharakterisierung nach einem Top-Down Ansatz 
untersttttzt wird. Die charakteristischen Funktionen fur die Fahrbarkeit sind jeweils in einem Plug-In 
konzentriert. Ein applizierbares Priorisierungsverfahren ermoghcht die flexible Koordination der Plug-Ins. 
Es gelingt dadurch, mit geringem Softwareaufwand vOllig unterschiedliche Fahrzeugcharaktere 
25 darzustellen. Definierte Schnittstellen erlauben die modulare Integration zusatzlicher Systemelemente. 
Das Plug-In Konzept erleichtert ein Softwaresharing, welches dem OEM (original equipment 
manufacturer, d. h. Automobilhersteller) die MOglichkeit gibt, seine Marke durch selbstMndig entwickelte 
Softwaremodule zu charakterisieren. Ein hohes MaS an Wiederverwendbarkeit der zugrunde Hegenden 
Softwarekomponenten unterstatzt die Anforderungen nach Kostengttnstigkeit und Softwarequalitat. 

30 

t. 

In Kraftfahrzeugen muss normalerweise zwischen unterschiedlichen VortriebswUnschen, die entweder 
vom Fahrer oder von Assistenzsystemen, z. B. FGR, ACC und ANB, kommen, gewahlt werden. Die 
Steuergeratesoftware enthait einen Programmteil, der den wichtigsten Anforderer auswahlt 
Wahrend der Implementierung des Auswahlverfahrens ist bekannt, welche Systeme Anforderungen stellen 
35 kdnnen und wie sie untereinander gewichtet sind. Diese Anforderungen werden in einer starren Logik 
miteinander verknttpft 
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Die bisher eingesetzten Verfahren haben den Nachteil, dass im Vorhinein bekannt sein muss, welches 
System Vortriebswtinsche geben kann und welche Anforderungskombinationen es geben kann. Dadurch 
muss ftlr jede Kombination von Systemen das Verfahren angepasst werden. 

5 Ziel der Erfindung ist ein Verfahren, mit dem man die Auswahl der weitergeleiteten Anforderung bzw. des 
Wunsches, insbesondere des Vortriebswunsches, unabhangig von der Anzahl und der Funktionsweise der 
anfordernden Systeme trefFen kann. 

Mit Hilfe eines erfindungsgemaBen Priorisierungsverfahrens, insbesondere als lineare Priorisierung oder 
10 als Maximal-(Minimal-) Auswahl, kann die Auswahl eines weitergeleiteten Anforderers bzw. Plug-Ins 
unabhangig von der Anzahl und der Funktionsweise der anfordernden Systeme getroffen werden. Bei der 
linearen Priorisierung wird eine Liste bzw. Tabelle von Anforderern sequentiell beginnend mit dem 
Anforderer mit der hochsten Prioritat abgearbeitet, wobei diese Liste fur die lineare Priorisierung sortiert 
ist nach dem Grad der Prioritat der Anforderer. Der Abbruch des Abfragens der Liste erfolgt, sobald ein 
15 Anforderer einen Anforderungswunsch enthalt. Dieser Anforderer wird damit ausgewahlt. Die ubrigen 
noch nicht abgefragten Anforderer werden somit nicht berUcksichtigt. 

Bei der Max-(Min-)Auswahl werden alle Anforderer abgefragt, die in der Liste fur die Max-(Min-) 
Auswahl stehen. Es wird derjenige Anforderer mit dem maximalen (minimalen) Anforderungswunsch 

2 0 ausgewahlt. 

Es kOnnen auch beide Verfahren beliebig miteinander kombiniert werden, beispielsweise indem zuerst 
eine lineare Priorisierung durchgefuhrt wird und daran anschlieBend eine Min-Auswahl, falls die lineare 
Priorisierung kein Ergebnis liefert. 

25 

Im Folgenden wird beispielhaft der Ablauf einer Auswahl eines Vortriebswunsches beschrieben. Das 
System beinhaltet z. B. die folgenden Anforderer: 

Fahrpedal (ID 10) 

Automatische Notbremse (ID 9) 

3 0 - Bremspedal (ID 35) 

FGR(ID44) 
Leerlaufiregler (ID 22). 

Das im Beispiel angewendete Verfahren, urn den wichtigsten Vortriebswunsch zu ermitteln, besteht aus 2 
35 Stufen: 

Lineare Priorisierung (z. B. als 1. Stufe) 
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Hier wird eine Liste sequenziell durchgearbeitet und sobald ein Anforderer einen 
Anforderungswunsch hat, abgebrochen. Je hoher ein Anforderer in der Liste stent, je heher ist 
seine Prioritat, 

Max-Auswahl (z. B. als 2.Stufe) 
5 Es werden alle Anforderer abgefragt. Es wird der Wunsch mit beispielsweise dem hochsten 

Vortriebsmoment ausgewahlt. 

In Fig. 9 ist eine grafische Darstellung einer linearen Priorisierung (1. Stufe) und eine Max-Auswahl (2. 
Stufe) dargestellt Bei der linearen Priorisierung hat der Anforderer ID9 (automatische Notbremse) die 
hochste Prioritat und wird zuerst abgefiragt. Der Anforderer ID35 (Bremspedal) hat eine nachgeordnete 
Prioritat, d. h. er wird nachfolgend abgefragt. In der Max-Auswahl (2. Stufe) sind die Anforderer ID10 
(Fahrpedal), ID44 (FGR) und DD22 (Leerlaufregler) gleichwertig auf der gleichen Priorisierungsstufe und 
werden alle abgefragt. Der Wunsch mit z. B. dem hGchsten Vortriebsmoment wird ausgewahlt. Beide 
Verfahren kSnnen sowohl getrennt als auch in Kombination angewendet werden. 

Fig. 10 zeigt ein Ablaufschema eines Priorisierungsverfahrens, wobei die lineare Priorisierung (1. Stufe) 1 
mit der Max-Auswahl (2. Stufe) 2 miteinander kombiniert sind. Die linke Halfte zeigt das lineare 
Priorisierungsverfahren 1 und die rechte Halfte die Max-Auswahl 2. Im linearen Priorisierungsverfahren 1 
wird im ersten Operationsschritt 3 zunachst abgefiragt, ob noch unbearbeitete IDs vorhanden sind, z. B. 
entsprechend Fig. 9 ID9 und ID35. Im Operationsschritt 4 wird auf die Abfrage, ob eine ID eine 
Anforderung hat, bei "ja" die Anforderung gespeichert 5 und weitergeleitet 6 und damit das Verfahren 
bzw. Ablaufschema abgebrochen, falls "nein" wird zuiiickgehend auf den vorhergehenden 
Operationsschritt 3 erneut abgefragt, ob noch unbearbeitete IDs vorhanden sind und das Verfahren so 
lange fortgesetzt, bis einen ID mit Anforderung vorhanden ist. Die Bearbeitung der IDs erfolgt in der 
Reihenfolge ihrer Priorisierung, z. B. bei Fig. 9 ID9 und danach ED35. Falls keine der IDs in der 1. Stufe 
tlber eine Anforderung verfiigt, wird zu den IDs der 2. Stufe tibergegangen, z. B. in Fig. 9, ID10, ID44 
und ED22. 

In der 2. Stufe mit Max-Auswahl 2 wird im ersten Operationsschritt 7 abgefragt, ob noch unbearbeitete 
30 IDs vorhanden sind. Falls "ja", wird im nachsten Operationsschritt 8 abgefragt, ob ein ID eine 
Anforderung hat. Falls keine Anforderung vorhanden ist, wird auf den vorhergehenden Operationsschritt 7 
zurilckgegangen und falls "ja" wird im nachsten Operationsschritt 9 verglichen, ob der gerade abgefragte 
Anforderer griifler ist als ein bereits gespeicherter Anforderer. Falls "nein", wird in Operationsschritt 7 
zurttckgesprungen, und fells "ja", wird die Anforderung gespeichert 5. Sind alle IDs der 2. Stufe 
35 abgefragt, d. h. in Operationsschritt 7 keine unbearbeiteten IDs mehr vorhanden, wird auf 
Operationsschritt 6 zum Weiterleiten der gespeicherten Anforderung gesprungen. Dadurch kann fiir die 
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IDs der zweiten Stufe die grOBte Anforderung ermittelt und weitergeleitet werden, flails - da in 
Kombination mit der linearen Priorisierung verwendet - die IDs der 1. Stufe keine Anforderung enthalten. 

Als weiteres Verfahren kommt z. B. noch eine Mittelwertbildung oder ein Kombination dieser Verfahren 
5 in Betracht. Vielen realen Anwendungsfallen wird dieses Verfahren nicht gentigen. Im Folgenden sind 2 
weitere Ausbaustufen des Systems beschrieben: 

Erweiterung urn Min/Max-Auswahl 

Sobald die Anforderer nicht nur den Motor, sondem auch die Bremse ansteuem konnen, kommt 
10 man nicht mit dem im Beispiel beschrieben Verfahren aus, da ein Bremseneingriff 

gegebenenfalls eine hehere Prioritat haben soil, als ein Beschleunigungseingriff. Um diesem 
Umstand Rechnung zu tragen, muss die 2. Stufe von einer Max-Auswahl in eine Min/Max- 
Auswahl verandert werden. Die Min/Max-Auswahl funktioniert wie folgt: 

Sobald ein Anforderer einen BremseneingrifT anfordert, gewinnt der niedrigste Vortriebswunsch 
15 (maximale VerzSgerung). Wenn es keinen Bremseneingriff gibt, wird die maximale 

Beschleunigung ausgewahlt. 
Erweiterung um Autoritaten 

Das oben beschriebene Verfahren entspricht nicht den zurzeit tiblichen Verfahren, da das 
Fahrpedal einen Bremseingriff des FGR oder des ACC uberstirnmen kann. Aus diesem Grand 
2 0 kann das beschriebene Verfahren noch um eine Stufe erweitert werden, die Autoritaten genannt 

werden. 

Bei diesem Verfahren kann jeder Anforderer bestimmte Anforderungsbereiche wahrend der 
Min/Max-Auswahl ausblenden. Das bedeutet, dass z. B. das Fahrpedal alle Bremseneingriffe 
ausblenden kann. Dadurch werden alle Bremseneingriffe wahrend der Min/Max-Auswahl 

2 5 ignoriert, aber nicht z. B. die Bremse, die in der linearen Priorisierung angesiedelt ware. 

Um die IDs efifizient zu handhaben, werden sie in Listen verwaltet, die sequenziell abgearbeitet werden. 
Ein Anpassen der Prioritaten auf globale Optimierungskriterien (z. B. Okoabstimmung, Spoitabstimmung 
oder Wintererkennung) kann erfolgen, wenn die IDs in 2-dimensionalen Listen verwaltet werden und je 

3 0 nach globalem Optirnierungskriterium eine andere Reihe benutzt wird, 

Wenn nun ein Anforderer hinzugefugt werden soli, so ist er in die richtigen Tabellen einzutragen und wird 
damit automatisch bei der nachsten Auswahl mit berttcksichtigt 

Es muss ausgeschlossen werden, dass eine ungiiltige Anforderung an den Motor oder die Bremse 
35 weitergeleitet wird. Aus diesem Grund muss sichergestellt sein, dass das System entweder mit einem 
gttltigen Wert vorinitialisiert wird oder es muss garantiert sein, dass bei jeder Auswahl immer mindestens 
ein Anforderer einen Wert anfordert. 
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Bei den anonymen erfindungsgemaBen Priorisierungsverfahren von Informationsgebern weiB das 
Auswahlverfahren nicht, welche Qualitat der Anforderer hat. Die einzigen Infonnationen, die es hat, sind 
die ID und die Position in den jeweiligen Tabellen der Auswahlverfahren. Dies ftihrt dazu, dass es keine 
inneren Abhangigkeiten von Anforderer und Auswahlsystem gibt. Ein derartiges Auswahlverfahren ist 
immer dann notig, wenn man die Anzahl der Anforderer andern konnen soil, ohne den Code des 
Auswahlverfahrens zu andern. Dieses Verfahren kann z. B. in einer Motorsteuerung angewendet werden, 
wie das obige Beispiel zeigt. Es gibt aber noch viele weitere Produkte, bei denen dieses Verfahren 
Vorteile bringt 



Die Vorteile des Priorisierungsverfahrens sind z. B.: 

keine Abhangigkeiten zwischen Auswahlverfahren und Anforderer und damit vermehrten 

Software Reuse des Auswahlverfahrens und der Anforderer (FGR, Fahrpedal, ...), 

verminderter Code- und Rechenzeitverbrauch bei komplexen Systemen (viele Anforderer), da 

15 das Auswahlverfahren unabhangig ist von Querbeziehungen der Anforderer, 

leichtere Erweiterbarkeit des Systems (Hinzufiigen von weiteren Anforderern). Solange die 
Anforderer die angebotenen, abstrakten Schnittstelle benutzen kSnnen und genugend 
Speicherplatz filr die ID-Tabellen reserviert worden ist, Varm das System urn beliebig viele 
Anforderer erweitert werden, ohne Programmcode andern zu mussen. 

2 0 - Wechsel zwischen PrioritatensStzen wahrend der Laufzeit m5glich und 

das System kann in Zukunft um eine dynamische Anmeldung von Anforderern erweitert werden. 

Nachfolgend wird erfindungsgemSB eine weitere, konkrete inhaltliche Vorgehensweise fur einen 
modulartigen Systemaufbau beschrieben. 
25 ErfindungsgemaB wird ein Verfahren zur Steuerung, insbesondere ein Verfahren zur koordinierten 
Antriebsstrangsteuerung von Kraftfahrzeugen in 5 Phasen bzw. Schritte eingeteilt: 

1 . Charakterisierung der Umwelteinflusse 

2. Festlegen eines globalen Optimierungskriteriums 

3 . Fahrerwunschinterpretation 

30 4. Optimalen Betriebspunkt bestimmen 

5 . Optimalen Betriebspunkt anfahren 

Im 1. Schritt der koordinierten Antriebsstrangsteuerung werden aktuelle Umweltdaten aufbereitet, 
gegebenenfalls typisiert und zur VerfUgung gestellt Folgende Informationsgruppen sind z. B. von 
35 Interesse: 

FahrzeuggrOBen: 

allgemeine aktuelle Fahrzeugdaten wie Geschwindigkeit und Querbeschleunigung 



WO 2004/014700: 




PCT/DE2003/002541 



Triebstrangzustand: 

aktuelle Triebstrangdaten wie Krafischluss und Schub/ Zug 
Fahrertyperkennung: 

beobachtet das Fahrverhalten und die Aktivitaten des Fahrers und leitet daraus einen abstrakten 
5 Typ ab (z. B. sportlich oder Skonomisch) 

Fahrsituationserkennung: 

zieht auf Grund abgeleiteter Signale RUckschlQsse auf die aktuelle Umwelt- oder Fahrsituation, z. 
B. Berg, Kurve, Winter, Stadt, Autobahn. 

Im 2. Schritt wird festgelegt, woraufhin das gesamte nachfolgende Verfahren optirniert werden soil. 
Denkbar sind beispielsweise Kriterien wie sportliche Fahrweise, akonomische Fahrweise oder besonders 
verschleifischonende Fahrweise. Der Vorteil der globalen Festlegung liegt in der anschlieBenden 
eiriheitlichen Verwendung in alien entscheidenden Funktionen von der Fahrpedalinterpretation bis zur 
Motormomenten- und Cbersetzungsauswahl. 

Die anschlieBende Fahrerwunschinterpretation im 3. Schritt hat die Aufgabe, die Vorgaben des Fahrers zu 
interpretieren und daraus eine Vorgabe fUr die LSngsbewegung des Fahrzeugs abzuleiten. Das umfaBt 
neben der reinen Fahrpedalinterpretation nach Beschleunigung und Verz5gerung beispielsweise auch die 
Vorgaben eines Fahrgeschwindigkeitsreglers oder eines ACC, die den Wunsch des Fahrers nach 
automatischer Fahrt mit konstanter Geschwindigkeit umsetzen. Eine Systemfuhrungsgr6l3e 
Getriebeausgangsmoment, die Beschleunigung und Verzogerung enthalt, wird in eine GrdBe 
Getriebeausgangsmoment fur den Antriebsstrang und eine Grofle FahrzeugverzGgerung fur die Bremse 
aufgeteilt 

2 5 Die Fahreiwimschinterpretation liefert als Ergebnis ein Getriebeausgangsmoment, das vom Antriebsstrang 
zur VerfUgung gestellt werden soli (hinzu kommt noch die bendtigte Nebenaggregateleistung). Hierftir 
muss nun ein optimaler Betriebspunkt im 4. Schritt bestimrnt werden, wobei sich "optimal 11 am 
ausgewahlten Optimierungskriterium (siehe 2. Schritt) orientieren sollte. Ein Betriebspunkt ergibt sich in 
einem konventionellen Antriebsstrang aus dem Motormoment und der Ubersetzung des Getriebes, da sich 

30 die Motordrehzahl bei gegebener Fahrzeuggeschwindigkeit direkt daraus berechnen lasst. Ftir zukUnftige 
Konzepte ergeben sich durch den Einbau weiterer Aggregate evt. noch weitere Freiheitsgrade (z. B. E- 
Maschine im 4-Quadranten-Betrieb). 



15 



Die letzte Aufgabe der koordinierten Antriebsstrangsteuerung ist das Anfahren des optirnalen 
3 5 Betriebspunktes im 5. Schritt. Der aktuelle und der neue optimale Betriebspunkt kdnnen unter Umstanden 
relativ weit "auseinander" liegen (z. B. wenn der Fahrer plOtzlich ins Fahrpedal tritt). Um Fahrbarkeit, 
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Kornfort, Sicherheit und Aggregateschutz zu gewahrleisten ist es daher hSufig sinnvoll, keinen abrupten 
Obergang (so schnell wie mSglich) zuzulassen, sondern den neuen Betriebspunkt gedampft anzufahren. 

Nach dem 5. Schritt steht der neue Betriebspunkt fest und die entsprechenden Vorgaben k6nnen an die 
5 Komponenten im Antriebsstrang ausgegeben werden. 

In den Phasen 2 bis 5 wird die eigentliche inhaltliche Ausgestaltung der Aufgabe der Pbase von Plug-Ins 
ubernommen. Dazu wird von jeder Phase eine entsprechende Schnittstelle angeboten, tlber die 
(mindestens) ein oder mehrere Plug-Ins VorschlSge oder Anforderungen einbringen kOnnen. Diese 
10 Vorschlage werden zunachst durch ein phasenspeziflsches, erfmdungsgemaBes Priorisierungsverfahren 
miteinander verglichen und der ausgewahlte Anforderungswunsch wird von der Phase anschlieBend 
tatsachlich als Vorgabe an die nachste Phase weitergegeben. Zur Priorisierung kommen verschiedene 
Verfahren zum Einsatz (einfache Rangfolge, Maximalauswahl, Mittelwertbildung und Kombinationen 
dieser Verfahren). 

15 

In Fig. 1 1 ist der erfindungsgemafie Ablauf noch einmal dargestellt. Der Ablauf der 5 Phasen ist im Sinne 
einer Zwischenschicht 11 (Layer, s. nSchster Absatz) zwischen Plug-Ins 10 und Triebstrangkomponenten 
12 dargestellt. Die Mbrmationen, die von einer Phase an die nachste Phase weitergegeben werden, sind 
mit 13 markiert. Anforderungen und Vorgaben, die zu den einzelnen Phasen von den Plug-Ins gemacht 
20 werden, sind mit 14 gekennzeichnet. Die Vorgabe des in der letzten Phase endgttltig festgelegten neuen 
Betriebspunktes an die Triebstrangkomponenten 12 ist mit 15 gekennzeichnet Die Pfeile 16 kennzeichnen 
den Informationsfluss allgemeiner Zustandsgr5Ben und FahrzeuggrSBen, die innerhalb der Phasen oder 
Plug-Ins zur Bearbeitung ihrer Funktion verwendet werden konnen. 

25 Zur Ausgestaltung der Phasen ist es gQnstig, eine entsprechend der Komponenten und Funktionen im 
Fahrzeug hierarchisch orientierte Struktur zu verwenden. Dazu wurde der modulartige Systemaufbau 
verwendet (s. Fig. 12). Diese bildet die Triebstrangtopologie in der Software ab und ermflglicht durch 
Mechanismen zur Austauschbarkeit die einfache Anpassung an Veranderungen der Fahrzeugkonfi- 
guration. Die Aufgaben der 5 Phasen wurden auf die Koordinatoren 17 verteilt, die inhaltlich fur diese 

3 0 Aufgabe vorgesehen sind. Zusatzlich sind so genannte "Interfaces" 18 eingefugt worden, die fur die 
Kommunikation mit den physikakschen Komponenten Motor, Getriebe und Bremse sorgen. 

Im Folgenden wird die Aufteilung der einzelnen Phasen innerhalb der erfmdungsgemaBen Struktur 
aufgezeigt sowie der Ablauf der gesamten erfindungsgemaBen Antriebsstrangsteuerung noch einmal im 
3 5 Detail insbesondere mit Hilfe von Beispielen erlautert: 
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In Fig. 13 ist die hierarchische Strukturierung bzw. Architektur als erfindungsgemafies objektorientiertes 
Softwaresystem zur koordinierten Antriebsstrangsteuerung dargestellt Sie ist in Form ineinander 
geschachtelter EUipsen bzw. Tropfen fiir Sofwarekomponenten aufgebaut, wobei eine in einer anderen 
grSBeren Ellipse angeordnete Softwarekomponente eine Teihnenge der grGBeren Softwarekomponente ist 
5 Es besteht die objektorientierte Gesamtsoftware (Vehicle, V) im Wesentlichen aus Fahizeugbewegnng 
(Vehicle Motion, VM), welches fiir die Ennittlung und Koordination aller I^gsdynamikaiiforderungen 
an das Fahrzeug verantwortlich ist, und dem Antriebsstrang (Powertrain, PT), der die Aufgabe hat, diese 
Anforderungen zu realisieren. Des Weiteren sind noch der Fahrzeugkoordinator (Vehicle Coordinator, 
VC), der Kriterienkoordinator (Criteria Coordinator, CC), die Schnittstellen nach innen und aufien 
10 (Interface In and Out), die (spezielle) Anwendungsschnittstelle (Application Progranaming Interface, API) 
und die hier mit Fragezeichen gekennzeichneten Komponenten fur Umweltgrdflen (Environment data, 
ED), z. B. Winter, FahrzustandsgrdBen (Driving Condition Data, DD), z. B. Geschwindigkeit, 
BenutzergrflBen (User Data, UD), z. B. Fahrertyp und FahrzeuggreBen (Vehicle Data, VD) dargestellt 
Die FuhrungsgroBe, auf die sich das gesamte System bezieht, ist das Getriebeausgangsmoment 

15 

Das System ist damit erweitert um Schnittstellen nach AuBen (Interface In and Out), die andeuten sollen, 
dass die einzelnen Softwarekomponenten fiir eine funktionstttchtige Software auch mit den realen 
Komponenten verbunden und mit weiteren Steuersystemen vernetzt werden mussen, und dass hierfur ein 
spezieller softwaretechnischer Mechanismus genutzt wird. 

2 0 Eine Sonderstellung nimmt die Schnittstelle (Criteria Coordinator) zu einer unbestimmten Anzahl Plug-In- 
Komponenten (Crit x) ein. Um das System einfach um beHebige Funktionen zur koordinierten 
Antriebsstrangsteuerung erweitern zu kdnnen, werden diese in Plug-Ins ausgelagert und kornmunizieren 
mit dem System ttber eine definierte Schnittstelle. Wie die funktionale Aufteilung zwischen dem System 
und den Plug-Ins und die dazugeherige Kommunikation ablauft, wird an Hand der folgenden Figuren 

25 beschrieben. 

Figur 14 zeigt die 5 Schritte des erfindungsgemaBen Verfahrens zur Steuerung, insbesondere zur 
koordinierten Antriebsstrangsteuerung von Kraftfahrzeugen. Im 1. Schritt erfolgt die Charakterisierung 
der Umwelteinflusse in der Informationsgruppe Fahrsituationserkennung, Fahrertyperkennung, 
30 FahrzeuggrOBen und Triebstrangzustand. Im 2. Schritt werden die Optimierungskriterien festgelegt, z. B. 
Verbrauch, Komfort, Leistung, Emission, Dynamik und VerschleiB. Anhand der Fahrpedalstellung wird 
im 3. Schritt die Fahrerwunschinterpretation durchgefuhrt. Im 4. Schritt wird der optimale Betriebspunkt 
bestimmt und im 5. Schritt angefahren, indem an Motor und Getriebe entsprechende Vorgaben gernacht 
werden. 

35 

In Fig. 14 werden im 1. Schritt der koordinierten Antriebsstrangsteuerung die aktuellen Umweltdaten bzw. 
Umwelteinflusse aufbereitet, gegebenenfalls typisiert und zur Verfiigung gestellt: 
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Fahrzeuggr5Ben: 

aUgemeine aktuelle Fahrzeugdaten wie Geschwindigkeit und Querbeschleunigung, 
Triebstrangzustand: 

aktuelle Triebstrangdaten wie Kraftschluss und Schub/Zug, 
Fabrertyperkennung: 

beobachtet das Fahrverhalten und die Aktivitaten des Fahrers und leitet daraus einen abstrakten 
Typ ab (z. B. sportlich oder flkonomisch), 
Fahrsituationserkennung: 

zieht auf Grund abgeleiteter Signale Rtlckschlusse auf die aktuelle Umwelt- oder Fahrsituation, z. 
B. Berg, Kurve, Winter, Stadt, Autobahn. 

Die Zuordnung der Charakterisierung der Umwelteinflttsse zur Architektur erfolgt an Hand Fig. 13. Die 
Fahrertyperkennung, Fahrsituationserkennung und FahrzeuggroBen werden den Infogebern ED, DD, Ud 
15 und VD auf der obersten Ebene zugewiesen und sind daher fur alle anderen Komponenten sichtbar, die 
TriebstrangzustandsgroBen pd (Powertrain Data) werden im Antriebsstrang ermittelt und kOnnen daher 
auch nur innerhalb des Antriebsstrangs direkt verwendet werden. 

Im 2. Schritt wird entsprechend Fig. 14 festgelegt, woraufhin das gesamte nachfolgende Verfahren 
2 0 optirniert werden soli. Denkbar sind beispielsweise Kriterien wie sportliche Fahrweise, okonomische 
Fahrweise oder besonders VerschleiB schonende Fahrweise. Der Vorteil der globalen Festlegung liegt in 
der anschlieBenden einheitlichen Verwendung in alien entscheidenden Funktionen von der 
Fahrpedalinterpretation bis zur Motorrnomenten- und Obersetzungsauswahl. 

Die Auswahl des aktuellen Optirrderungskriteriums wird entsprechend Fig. 15 vom Fahrzeugkoordinator 
(Vehicle Coordinator, VC) gesteuert. Dieser fragt Vorschiage von Plug-Ins (Crit x) Uber eine spezielle 
Schnittstelle, den Kriterienkoordinator (Criteria Coordinator, CC) ab und priorisiert diese lediglich. Wie 
die Plug-Ins die Aufgabe erledigen, einen Vorschlag zu ermitteln, und urn welche Art von Plug-Ins es sich 
jeweils handelt, ist dem Fahrzeugkoordinator dabei nicht bekannt 

In Fig. 16 ist ein beispielhafter Priorisierungsablauf entsprechend Fig. 15 zur Auswahl des 
OpthTnerungskriteriurns durch den Fahrzeugkoordinator dargestellt. 

Der Ablauf, der auf der linken Seite von Fig. 16 exemplarisch gezeigt ist, geht von Plug-Ins aus, wie sie 
35 als Beispiel auf der rechten Seite dargestellt sind. 

In diesem Beispiel gibt es in der Reihenfolge ihrer "Wichtigkeit" die drei Plug-Ins "Winter", "Sport" und 
"Normalfahrt". Diese haben bis auf Normalfahrt die Eigenschaft, nur dann einen Vorschlag fur das 
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Optimierungskriterium zu machen (sprich, sie sind nur dann "aktiv"), wenn eine bestimmte Situation 
vorliegt, wenn diese nicht vorliegt, machen sie keinen Vorschlag (sind also "inaktiv"). Nonnalfahrt ist 
insofern eine Ausnahme, da es ohne Vorliegen einer bestimmten Bedingung iromer aktiv ist 

5 Der Ablauf wird folgendennaBen beschrieben: Vor dem Doppelpunkt ganz links steht das Objekt, das eine 
Tatigkeit auslOst und ein anderes Objekt aufruft. Nach dem Doppelpunkt rechts steht die Methode des 
aufgerufenen Objekts. 

Der Fahrzeugkoordinator ruft zunSchst den Kriterienkoordinator auf, einen Vorschlag fur eine 
10 Fahrzeugopthiiierung vom Plug-In mit der ID 1 abzufragen. Der Kriterienkoordinator kennt das mit der 
ID1 benannte Plug-In und holt sich von diesem den aktuellen Optimierungsvorischlag. Da die 
Fahrsituation Winter aber im Beispiel nicht aktiv ist, gibt es "None", also keinen Vorschlag zurttck. 

Der Aufruf des nachsten Plug-Ins erfolgt auf die gleiche Art und Weise, dieses gibt jedoch den 
15 Optimierungsvorschlag "Sport" zurttck, da der Fahrertyp "sportlich" ist. 

Da nun ein Vorschlag fur ein Optimierungskriterium gefunden ist, brauchen nachfolgende Plug-Ins mit 
einer niedrigeren Prioritat nicht mehr nach einem Vorschlag befragt werden. 

20 Das vorgeschlagene Priorisierungsverfahren an dieser Stelle ist mOglichst einfach, es wird eine feste 
Rangfolge festgelegt und das ranghOchste aktive Kriterium, das nicht "None" zurttckliefert, gewinnt Ein 
Vorteil dieser Priorisierung liegt darin, dass nicht immer alle Kriterien befragt werden miissen, da in dem 
Moment abgebrochen werden kann, wenn ein aktives Kriterium gefunden wurde. 

2 5 Als Schnittstelle zwischen dem Fahrzeugkoordinator und den Plug-In wird (fur alle Plug-Ins einheitlich) 

eine feste Menge von Zustanden vereinbart. Die gewttnschte Bedeutung wie z. B. "Sport" oder 
"Verschleifl" muss auf beiden Seiten bekannt sein, da der Fahrzeugkoordinator dementsprechende 
MaBnahmen einleiten k5nnen soil (Aufruf Crit_GetJVehOpt()). 

3 0 Die Fahrerwunschinterpretation als 3. Schritt gemaB Fig. 14 hat die Aufgabe, die Vorgaben des Fahrers zu 

interpretieren und eine Vorgabe fur die Langsbewegung des Fahrzeugs daraus abzuleiten. Das umfaBt 
neben der reinen Fahrpedalinterpretation beispielsweise auch die Vorgaben eines 
Fahrgeschwindigkeitsreglers oder eines ACC, die den Wunsch des Fahrers nach automatischer Fahrt mit 
konstanter Geschwindigkeit umsetzen. Als Schnittstelle zum Antriebsstrang bzw. zur Bremse sind 
3 5 Getriebeausgangsmoment und FahrzeugverzCgerung vorgesehen 
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Den Ablauf der Fahrerwunschinterpretation entsprechend Fig. 17 steuert der Vortriebs- und 
Bremskoordinator (Propulsion and Brakes Coordinator, PrBC). Dieser ennittelt in Zusammenarbeit mit 
einer unbestimmten Anzahl von Plug-Ins nach einem speziellen Priorisierungsverfahren die Vorgaben flir 
Bremse und Antriebsstrang. Der Fahizeugbewegungskoordinator (Vehicle Motion Coordinator, VMC) 
5 koordiniert diese langsamen Vorgaben noch mit den schnellen Eingriffen der Traktions- und 
Fahrstabilit&tssysteme (ESP) (die Begriffe langsam und schnell sollen hier andeuten, daB die 
Reaktionszeiten eines normalen Fahrers im Vergleich zu den Reaktionszeiten eines elektronischen 
Systems „lang" sind) und gibt die so gewonnenen Forderungen an den Triebstrang (Propulsion System, 
PrSy) bzw. das Bremssystem (Brake System, BrSy) weiter, wobei die weitere Auswertung und 
1 0 Durchftihrung der Vorgaben an die Bremse nicht Teil dieser Darstellung sind. 

Zusatzlich bietet der Kriterienkoordinator noch eine spezielle Schnittstelle (Application Programming 
Interface, API) zur Umrechnung einer Fahrzeugbeschleunigung in das dafUr zum aktuellen Zeitpunkt 
benStigte Getriebeausgangsmoment und umgekehrt an, wobei der Kriterienkoordinator diese Aufgabe 
15 nicht selber erfiillt, sondern z. B. an den Triebstrang weiterleitet, da dieser die relativ aufwendige 
Umrechnung zur Bewaltigung seiner Aufgaben eh beinhaltet. Dadurch ergeben sich Vorteile bei der 
Umsetzung der Plug-Ins: 

Die Plug-Ins werden einfacher, tlbersichtlicher und kleiner, 
die Plug-Ins werden unabhangig von fahrzeugspezifischen Daten und 
20 - der Gesamtsoftwareumfang wird geringer. 

In Fig. 18 ist ein beispielhafter Priorisierungsablauf analog Fig. 16 entsprechend Fig. 17 zur 
Fahrerwunschinterpretation dargestellt 

25 Der Beispielablauf zur Fahrerwunschinterpretation in Fig. 18 orientiert sich an den Plug-Ins 
Fahrgeschwindigkeitsregler (FGR), Beschleunigungspedal und ,t Standard , '-Fahrpedal mit den folgenden 
Funktionsweisen: 

Der Fahrgeschwindigkeitsregler versucht eine stationSre Geschwindigkeit durch die Anforderung einer 
30 Sollbeschleunigung einzuregeln, wenn der Fahrer diesen aktiviert hat. Das BescMeunigungspedal 
interpretiert die Fahrpedalstellung des Fahrers als Beschleunigungswunsch. Das Standard-Fahrpedal 
interpretiert die Fahrpedalstellung des Fahrers geschwindigkeitsabhangig als Getriebeausgangsmoment. 

Der Vortriebs- und Bremskoordinator fragt tlber den Kriterienkoordinator zunachst das Plug-In tmt der 
35 ID1 (Fahrgeschwindigkeitsregler) nach dessen Vortriebswunsch. Dies liefert einen Wunsch nach einer 
Beschleunigung von 1,1 m/s 2 zurttck. Die Forderung, die der PrBC nach auBen weitergeben kann, ist 
jedoch Getriebeausgangsmoment und Bremsverzdgerung. Daher beauftragt er den Beschleunigungs- 
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manager (Acceleration Request Manager, AccRM) damit, eine Standardaufteilung der geforderten 
Beschleunigung auf Vortrieb und Bremse durchzuflihren. Diese ergibt ein Getriebeausgangsmoment von 
160 Nm und keine VerzSgerung. 

5 AnschlieBend wird das Plug-In mit der ID2 aufgerufen. Das Beschleunigungspedal ermittelt eine 
gewUnschte Beschleunigung von 1,2 m/s 2 durch die Fahrervorgabe am Fakrpedal. Die Aufteilung auf 
Vortrieb und Bremse erledigt dieses Plug-In jedoch selber tiber das API des Kriterienkoordinators und 
gibt einen Vortriebswunsch von 170 Nm und keine VerzOgerung an den Koordinator zurtlck. 

10 Das dritte Plug-In Standard-Fahrpedal wird nicht aufgerufen. Im vorherigen Schritt (Festlegen der 
Optirrnerungskriterien) wurde als aktuelles Optimierungskriterium "Sport" festgestellt. Bei diesem 
Optimierungskriterium wird in der Fahrerwunschinterpretation anstelle des Standard-Fahrpedals in diesem 
Beispiel das Beschleunigungspedal aufgerufen, das Standardpedal wird nicht bendtigt 

15 AbschlieBend wahlt der Koordinator das Plug-In mit der ID2 als Gewinner aus, da dessen Forderung den 
hachsten Betrag hatte. AuBerdem teilt er alien Plug-Ins mit, dass das Plug-In mit der ID2 gewonnen hat 
mit einer Forderung von 170 Nm Getriebeausgangsmoment und keiner VerzSgerung. Daraus kann der 
Fahrgeschwindigkeitsregler erkennen, dass sein Vorschlag durch ein anderes Plug-In uberstimmt wurde 
und dementsprechend reagieren (z. B. Festhalten des I-Anteils oder Deaktivierung). 

20 

Die Priorisierung der Fahrerwunschinterpretation ist eine Erweiterung des linearen Verfahrens: 

Aus der Menge aller Plug-Ins, die einen Vorschlag zur Fahrenvunschinterpretation machen konnen, 
werden nur die ausgewahlt, deren Vorschlag zum aktuellen Optierungskriterium pass! So kann z. B. je 

2 5 nach Optinrierung ein "normales" Fahrpedal gegen ein "sportliches" Fahrpedal ausgetauscht werden. 

AnschlieBend erfolgt eine lineare Priorisierung all derjenigen Plug-Ins, fUr die eine feste Rangfolge 
festgelegt werden kann. Dies kann beispielsweise fur ein Bremspedal geschehen, da bei der Betatigung 
der Bremse FGR und Fahrpedal inaktiv sein mtissen (allerdings nur bedingt, s. Bretttest). Wenn in dieser 

3 0 Phase ein Plug-In aktiv wird, bricht das Verfahren entsprechend der linearen Priorisierung ab. 

Wird jedoch kein Plug-In aktiv, so werden alle weiteren Plug-Ins, die sich nicht in eine feste Rangfolge 
ordnen lassen, aufgerufen. Die Priorisierung erfolgt dann aus der Menge aller Vorschlage durch eine 
Maximalauswahl. 

35 

Grundsatzlich werden damit nur die Kriterien herangezogen, die zum aktuellen Optimierungskriterium 
"passen"; die eigentliche Priorisierung erfolgt in einem zweistufigen Verfahren: 
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In einer ersten (applizierbaren) Tabelle wird ftir die Kriterien eine Reihenfolge festgelegt, nach der sie 
befragt werden. Sobald ein Wunsch erkannt wird, bricht das Verfahren ab. FUr einige Kriterien reicht 
diese einfache Priorisierung aus (z. B. bei einer Anforderung des Bremspedals, FGR und Fahrpedal 
brauchen dann nicht mehr befragt werden). 
5 Falls im ersten Schritt kein Wunsch ermittelt werden kann, wird in einem zweiten Schritt eine 

Maximalauswahl des Vortriebsmomentenwunsches aller in einer zweiten (ebenfalls applizierbaren) 
Tabelle verzeichneten Anforderer durchgefuhrt; sofern es mindestens einen negativen Momentenwunsch 
gibt, wird der kleinste negative Wunsch ausgewahlt, ansonsten der grdBte positive Momentenwunsch. 

10 In Fig. 19 ist eine beispielhafte Anforderung eines Plug-Ins dargestellt. 

Als Schnittstelle stehen den Plug-Ins im Gegensatz zum Vortriebs- und Bremskoordinator zwei 
Alternativen zur VerfUgung. Sie kdnnen entweder Getriebeausgangsmoment Mvortneb und 
BremsverzOgerung a Brems oder eine Summenbeschleunigung a Summ£ fordern. Wird von einem Plug-In eine 
15 Summenbeschleunigung angefordert, kann der Koordinator selber entscheiden, wie er diese auf Vortrieb 
und Bremse aufteilen will (mittels des BescMeunigungskoordinators). 

Urn zum einen das Erkennen eines nicht vorhandenen Vortriebswunsches (Plug-In ist inaktiv) zu 
erleichtern (0 Nm ist ein definitiver Vortriebswunsch und eignet sich daher nicht zur Kennzeichnung von 
2 0 "kein Wunsch") und zum anderen die verwendete Schnittstellenalternative anzuzeigen, wird vom Plug-In 
zusatzlich der Anforderungstyp 0,1 oder 2 vorgegeben. 

Die Fahren\oinschinteipretation Uefert als Ergebnis ein Getriebeausgangsmoment, das vom Antriebsstrang 
zur Verfligung gestellt werden soli (hinzu kommt noch die benBtigte Nebenaggregateleistung). Hierfur 

2 5 muss nun ein optimaler Betriebspunkt als 4. Schritt gemafl Fig. 14 bestimmt werden, wobei sich "optimal" 

am ausgewahlten Optimierungskriterium orientiert 

Ein Betriebspunkt ergibt sich in einem konventionellen Antriebsstrang aus dem Motormomentmoment 
und der Obersetzung des Getriebes, da sich die Motordrehzahl bei gegebener Fahrzeuggeschwindigkeit 

3 0 direkt daraus berechnen lasst Fur zukttnftige Konzepte ergeben sich durch den Einbau weiterer Aggregate 

evtl. noch weitere Freiheitsgrade (z. B. E-Maschine im 4-Quadranten-Betrieb). 



Die Bestimmung des optimalen Betriebspunktes gemafl Fig. 20 wird vom Antriebsstrangjcoordinator 
(Powertrain Coordinator, PTC) verwaltet. Dieser kommuniziert in tiblicher Weise mit den Plug-Ins tiber 
3 5 den Kriterienkoordinatpr. 
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In Fig. 21 ist ein beispielhafter Priorisierungsablauf analog Fig. 16 entsprechend Fig. 20 zur Bestimmung 
des optimalen Betriebspunktes dargestellt 

Der Ablauf zur Bestimmung des optimalen Betriebspunktes erfolgt wieder nach dem Schema lineare 
5 Priorisierung. Als Beispiel sind drei Plug-Ins mit den Aufgaben Sport, Berg und Okonomisch dargestellt 

Der Antriebsstrangkoordinator ruft den Kriterienkoordinator auf, einen Vorschlag fllr einen optimalen 
Betriebspunkt bei einem Vortriebsmoment von 1 80 Nm vom Plug-In mit der ID 1 abzufragen. 

1 0 Der Kriterienkoordinator kennt das mit der ID 1 benannte Plug-In und holt sich von diesem dem optimalen 
Betriebspunkt. Da die Fahrsituation Sport nicht aktiv ist, gibt es "None", also keinen Vorschlag, zurttck. 
Der Aufruf des nachsten Plug-Ins mit der ID2 erfolgt auf die gleiche Weise, dieses gibt einen optimalen 
Betriebspunkt mit einem Motorausgangsmoment von 170 Nm und einer Obersetzung von 0,666 an. 

15 Zur Priorisierung werden nur die Kriterien herangezogen, die zum aktuellen Optimierungskriterium 
"passen" (eine applizierbare Tabelle mit alien "passenden" Kriterien fur jedes Optimierungskriterium). 
Fur die Kriterien wird eine Reihenfolge festgelegt, nach der sie befragt werden (s. Fig. 21). Das Kriterium 
mit der hOchsten Prioritat wird zuerst befragt. Wenn es nicht aktiv ist, wird das nSchste befragt usw., bis 
das erste aktive Kriterium gefunden ist, danach bricht das Verfahren ab. 

2 0 Das erste aktive Kriterium wird verwendet. An der Schnittstelle erfolgt somit Folgendes: 
Aufruf: Crit_Get_OpPointProp (Getriebeausgangsmoment) 
Return: Motorausgangsmoment, Obersetzung. 

Die Plug-Ins werden aufgerufen, wobei ihnen das Sollgetriebeausgangsmoment als Parameter mit 
25 ttbergeben wird, damit die Plug-Ins wissen, fur welche Momentenforderung ein ihrer Aufgabe nach 
optimaler Vorschlag abgefragt wird 

Die letzte Aufgabe als 5. Schritt gemafi Fig. 14 der koordinierten Antriebsstrangsteuerung ist das 
Anfahren des optimalen Betriebspunktes. Der aktuelle und der neue optimale Betriebspunkt kdnnen unter 
30 Umstanden relativ weit "auseinander" liegen (z. B. wenn der Fahrer plfltzlich ins Fahrpedal tritt). Um 
Fahrbarkeit, Komfort, Sicherheit und Aggregateschutz zu gewahrleisten ist es daher Mufig sinnvoll, 
keinen abrupten Obergang (so schnell wie mOglich) zuzulassen, sondern den neuen Betriebspunkt 
gedampft anzufahren. 

35 Das Anfahren des optimalen Betriebspunktes gemSB Fig. 22 wird gemeinsam mit dem Besthmnen des 
optimalen Betriebspunktes vom Antriebsstrangkoordinator (Powertrain Coordinator, PTC) verwaltet. 
Dieser kommuniziert in tlbhcher Weise mit den Plug-Ins tlber den Kriterienkoordinator. 
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Das abschlieBend ermittelte Ergebnis wird vom Antriebsstrangkoordinator an die Komponenten Motor 
und Getriebe zur AusfUhrung weitergegeben. 

5 In Fig. 23 ist ein beispielhafter Priorisierungsablauf analog Fig. 16 entsprechend Fig. 22 zum Anfahren 
des optimalen Betriebspunktes dargestellt 

Der Ablauf zum Anfahren des optimalen Betriebspunktes basiert wieder auf dem linearen 
Priorisierungsverfahren. Als Beispiel sind die Plug-Ins Kurve, Winter und Berg ab dargestellt 

10 

Der Antriebsstrangkoordinator ruft den Kriterienkoordinator auf, einen Vorschlag fur eine 
Gradienteribegrenzung von Plug-Ins mit der DDI abzufragen. 

Der Kriterienkoordinator kennt das mit der ID1 benannte Plug-In und holt sich von diesem eine 
Gradientenbegrenzung. Da Critl nicht aktiv ist (Kurve, verhindert eine Anderung des 
15 Triebstrangzustandes in fahrdynamischen Grenzsituationen), gibt es "None", also keinen Vorschlag 
zurttck. 

Der Aufruf des nSchsten Plug-Ins mit der ID2 erfolgt auf die gleiche Weise, dieses gibt "None", also 
keinen Vorschlag, da auch Crit2 (Winter) nicht aktiv ist. 

20 Zur Priorisierung werden nur die Kriterien herangezogen, die zum aktuellen Betriebspunkt der 
Betriebspunktermittlung "passen" (eine applizierbare Tabelle bzw. Liste mit alien "passenden" Kriterien 
fur jedes Betriebspunktkriterium). 

Fttr die Kriterien wird eine Reihenfolge festgelegt, nach der sie befragt werden (s. Fig. 23). Das Kriterium 
mit der hdchsten Prioritat wird zuerst befragt. Wenn es nicht aktiv ist, wird das nSchste befragt usw., bis 
2 5 das erste aktive Kriterium gefunden ist, danach bricht das Verfahren ab. 

(Eine weitere Mdglichkeit ergibt sich, indem eine Max- oder Min- Auswahl aus alien Anforderungen 
durchgefuhrt wird.) 

An der Schnittstelle erfolgt Folgendes: 
3 0 Aufruf: Crit_Get_OpPointGrad0 

Return: Gradientenbegrenzung, z. B. in Form von Filterparametern, Min- und Max-Werten fiir 
Motormomenten- und Obersetzungsverstellung. 

Das Priorisierungsverfahren zum Anfahren des optimalen Betriebspunktes unterscheidet sich vom linearen 
35 Priorisierungsverfahren darin, dass es nicht ein Plug-In geben muss, das auch tatsachlich einen Vorschlag 
macht, alle Plug-Ins konnen "None" zurttckgeben, was dann als "so schnell wie mSglich" Anfahren des 
neuen Betriebspunktes inteipretiert wird 
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Die Schnittstelle fttr die Vorgaben der Plug-Ins kann recht vielMtig ausfallen. Denkbar sind 
Gradientenbegrenzungen, Filterparameter oder absolute Grenzen fttr Motormoment und Obersetzung. 

5 In Fig. 24 ist allgemein eine schematische Stnikturierung gemaB Fig. 13 bei der Benutzung einzelner 
Plug-Ins von verschiedenen Schnittstellen dargestellt 

Entsprechend den zugeteilten Aufgaben kBnnen einzelne Plug-Ins eine, mehrere oder alle Schnittstellen 
benutzen. Die nachfolgenden beispielhaften Plug-Ins Sport, Kriechen und Kurve nutzen somit 
1 0 unterschiedliche Schnittstellen: 

— Sport: 

- Anforderung sportliche Fahizeugoptimierung, 

- Anforderung sportliche Fahrpedalinterpretation durch andere Pedalkennlinie und weniger 
15 Lastschlagdampfung, 

- Anforderung sportliche Obersetzimgswahl mit hoher Momentenreserve durch h5here Drehzahl, 

- Anforderung sportliche Obersetzungsverstellung (schnell anstatt komfortabel ftir moglichst 

hohe Beschleunigung); 

— Kriechen: 

2 0 - Veranderte Fahrpedalinterpretation mit Bremseingriff, urn mdglichst einfaches Einparken zu 

ermdglichen; 

— Kurve: 

- Verhinderung von Ubersetzungsverstellungen bei Kurvenfahrt im Grenzbereich. 

2 5 AbschlieBend werden nochmals zusammenfassend die Vorteile der gesamten Erfindung aufgeflihrt: 

Eine Funktion im Sinne einer durch den Fahrer erkennbaren zusammenMngenden Funktionalitat 
hat haufig Anforderungen und Auswirkungen auf verschiedenste Komponenten im Fahrzeug. 
Beispielsweise kann ein adaptiver Geschwindigkeitsregler beim E inhalt en einer durch den Fahrer 
30 vorgegebenen Geschwindigkeit sowohl beschleunigen als auch verzdgem. Dazu mQssen die 

Komponenten Motor, Getriebe und Bremse entsprechend angesteuert werden. Dies wird im 
beschriebenen System mOglich gemacht, ohne dass die Funktionalitat auf verschiedene 
Komponenten aufgeteilt werden muss. Die Funktionalitat bleibt als Einheit zusammen und kann 
dem System hinzugeftlgt oder entnommen werden, ohne dass dafUr die Software oder Hardware 

3 5 des Systems geandert werden muss. 
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In dieses optimierte System konnen dann Anforderungen verschiedenster Systeme in 
einheitlicher Art anf Basis von SystemftihrungsgrQBen (im Wesentlichen dem 
Getriebeausgangsmoment) zentral eingebracht werden. 

In dieses optimierte System kfinnen verschiedenste Verfehren zur Ermittlung von geeigneten 
5 Betriebspunkten des Antriebsstranges eingebracht werden. 

In diesem optimierten System kOnnen die Anforderungen und Verfehren entsprechend der 
aktuellen Fahrsituation durch ein abstraktes Priorisierungsverfahren situationsgerecht priorisiert 
werden, so dass die "richtige" Anforderung berttcksichtigt und das "optimale" Verfehren zur 
B etriebspunktauswahl verwendet wird. 

10 - Dieses optimierte System rechnet die Anforderungen entsprechend der Triebstrangtopologie des 

betreffenden Fahizeugs urn und macht Vorgaben an die Triebstrangkomponenten, wobei die 
Schnittstellen zu den Komponenten so abstrakt wie mOglich auf physikalischer Basis festgelegt 
werden, urn Abhangigkeiten beispielsweise von verschiedenen Motortypen (Diesel und Benzin) 
weitestgehend auszuschalten. 

15 - Dieses System bietet die Mflglichkeit, die Ermittlung von Anforderungen und Verfehren zur 

Berechnung von optimalen Betriebspunkten in Plug-Ins zusammenzufassen, urn so separierbare 
Systeme im Sinne von veraufierbaren Produkten zu schafFen. 

Eine Funktion im Sinne einer durch den Fahrer erkennbaren zusammenhangenden Funktionalitat 
hat haufig Anforderungen und Auswirkungen auf verschiedenste Komponenten im Fahrzeug. 

2 0 Beispielsweise kann ein adaptiver Geschwindigkeitsregjer beim Einhalten einer durch den Fahrer 

vorgegebenen Geschwindigkeit sowohl beschleunigen als auch verzSgera. Dazu mtissen die 
Komponenten Motor, Getriebe und Bremse entsprechend angesteuert werden. Dies wird im 
beschriebenen System mdglich gemacht, ohne dass die Funktionalitat auf verschiedene 
Komponenten aufgeteilt werden muss. Die Funktionalitat bleibt als Einheit zusammen und kann 
25 dem System hinzugefllgt oder entnommen werden, ohne dass dafttr das Programm des Systems 

geandert werden muss. 

Die Priorisierungsverfahren zur Auswertung der Anforderungen verschiedener Plug-Ins kdnnen 
auf Grund deren EinheitHchkeit (alle Plug-Ins fordern zur Beschleunigung des Fahizeugs ein 
Getriebeausgangsmoment (FtlhrungsgrdBe des Systems) so ausgelegt werden, dass zur 

3 0 Priorisierung nicht bekannt sein muss, welches System hinter der Anforderung steht (es spielt aus 

Sicht des Priorisierungsverfahrens keine Rolle, welche FunktionaUtat ein Plug-In erfUllt, sondern 
nur, welche Prioritat es hat). Durch diese Anonymisierung der Anforderer ist es mOglich, die 
Anzahl der zu berttcksichtigenden Plug-Ins frei zu wahlen, ohne daftir das Programm andem zu 
mtissen. Dadurch vereinfecht sich die Konfiguration des Systems zur Anpassung an eine 
35 besthnmte Fahizeug- und Funktionsvariante erheblich und es kdnnen auch nachtraglich noch 

Funktionen hinzugefUgt werden, die zunachst nicht mit eingeplant waren. 
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Zu den Komponenten im Triebstrang entstehen einheitliche, abstrakte Schnittstellen, die weitest- 
gehend von Varianten der Komponenten unabhangig sind. Dadnrch k6nnen bei Einhaltung der 
Schnittstellen sehr einfach Komponenten unterschiedlicher Hersteller eingesetzt werden, 
wodurch sich der Fahrzeughersteller nicht von proprietaren LSsungen einzelner Zulieferer 
5 abhangig macht 

Die Programme der Plug-Ins k5nnen weitestgehend ohne Kenntnisse von der Art eingesetzter 
Komponenten definiert werden und dadurch in vielen Fahrzeugkonfigurationen wieder 
verwendet werden. Dies ist bei der hohen Zahl an Fahrzeugvarianten ein deutlicher Vorteil. Ein 
typisches Beispiel ist der Fahrgeschwindigkeitsregler, der sich heute intern stark unterscheidet, je 
10 nachdem ob ein Diesel- oder ein Benzinmotor das Fahrzeug antreibt. Das beschriebene System 

wirkt wie eine Zwischenschicht, die die Funktionalitaten, die in Plug-Ins abgebildet werden, von 
den Komponenten entkoppelt. Ein weiterer positiver EfFekt der Entkopplung ist die Reduktion 
des AppHkationsaufwandes, der sonst haufig durch Anderungen in anderen Funktionen oder 
Komponenten erzeugt wird. 



15 
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Ansprttche 



10 1. 

15 

20 

2. 

25 

3. 

30 

4. 

35 



Computersystem mit wenigstens einem Prozessor und wenigstens einem Speicher zur 
Steuerung, insbesondere zur koordinierten Antriebsstrangsteuerung fUr ein Kraftfahrzeug, mit 
einer Softwarearchitektur mit im Wesentlichen folgenden Elementen bzw. Komponenten: 

ein Operation System and Specific Services mit Betriebssystem und speziflschen 

Diensten als Basis fur alle anderen Elemente und Anwendungen, 

eine Basic Functionality zur Umsetzung universeller Anforderungen, 

einen Layer zur Koordinierung von Aufgaben fur Basisfunktionalitaten der Basic 

Functionality und zur Einbindung von Plug-Ins, 

wenigstens ein Plug-In zur Umsetzung von konkreten Aufgaben bzw. Funktionen, die 
tiber die Basisfunktionalitat hinausgehen und vom Layer koordiniert werden, wobei die 
Plug-Ins insbesondere modulartig austauschbar sind. 

Computersystem nach Anspruch 1, 
dadurch gekennzeichnet, 

dass in der Softwarearchitektur offene Schnittstellen (Open Interfaces) auf die von auBen 
zugegriffen werden kann und/oder geschlossene Schnittstellen (Incapsulated Interfaces), die 
nach auBen nicht fxeigegeben sind, integriert sind. 

Computersystem nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

dass als Plug-Ins beispielsweise ein ACC (Adaptive Cruise Control)-Request, ein Drivers 
Demand (comfort/sport), Driveability oder Shift Strategic (comfort/sport) verwendet werden. 

Computersystem nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

dass der Layer die Koordinatoren Vehicle Coordinator, Vehicle Motion Coordinator und 
Powertrain Coordinator umfasst. 
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5. Computersystem nach Anspruch 4, 
dadurch gekennzeichnet, 

dass jeder Koordinator Uber Schnittstellen mit den Plug-Ins zur Kommunikation verbunden ist. 

6. Computersystem nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

dass der Layer ttber Schnittstellen zur Kommunikation mit der Basic Functionality verbunden 
ist, welche Basisfunktionen enthalt, die wie Sensoren oder Aktoren agieren. 

7. Computersystem nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

dass durch die modulartige Austauschbarkeit der Plug-Ins das Computersystem flexibel an 
unterschiedliche Fahrzeug- und Steuergeratekonfigurationen anpassbar ist und Funktionen 
einfach implementierbar sind, wobei Anforderungen verschiedener Systeme in einheitlicher Art 
auf Basis von SystemflihrungsgrGBen, z. B. Getriebeausgangsmoment, zentral eingebracht 
werden. 

8. Priorisierungsverfahren von Informationsgebeni, z. B. Plug-Ins, insbesondere zur koordinierten 
Antriebsstrangsteuerung fur ein Kraftfahrzeug, insbesondere durchgefuhrt mit einem 
Computersystem nach einem der Anspriiche 1 bis 7, wobei: 

eine Liste mit Anforderern bzw. Plug-Ins nach dem Grad der Prioritat aufsteigend oder 
abfallend sortiert wird, 

die sortierte Liste sequentiell beginnend mit dem Anforderer bzw. Plug-In mit der 
hOchsten Prioritat abgearbeitet wird, 

das Abarbeiten der Liste abgebrochen wird, sobald ein Anforderer bzw. Plug-In einen 
Anforderungswunsch enthalt, urn diesen Anforderungswunsch auszuwShlen. 

9. Priorisierungsverfahren nach Anspruche 8, 
dadurch gekennzeichnet, 

dass der ausgewShlte Anforderungswunsch gespeichert und weitergeleitet wird. 

10. Priorisierungsverfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, 

dass verschiedene Listen zum Anpassen auf globale Optimierungskriterien, z. B. 
Okoabstimmung, Sportabstimmung oder Wintererkennung, abgearbeitet werden. 



1 1 . Priorisierungsverfahren nach einem der Anspriiche 8 bis 1 0, 
dadurch gekennzeichnet, 
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12. 

5 



10 



13. 

15 



20 
25 

14. 

30 



15. 

35 



dass jeder Anforderer bzw. jedes Plug-In durch eine Identitat (ED), vorzugsweise als Zahl, und 
eine Position in den verschiedenen Listen filr das Abarbeiten eindeutig gekennzeichnet ist 

Priorisierungsverfabren von Infoimationsgebern, z. B. Plug-Ins, zur Steuerung, insbesondere 
zur koordinierten Antriebsstrangsteuerung fur ein Kraftfahrzeug, insbesondere durchgefiihrt mit 
einem Computersystem nach einem der Ansprtlche 1 bis 7, mit im Wesentlichen den 
nachfoigenden Schritten: 

in einer Liste mit Anforderern bzw. Plug-Ins werden alle Anforderer in beliebiger 

Reihenfolge abgearbeitet, beispielsweise sequentiell, 

aus den Anfordemngswtinschen der Anforderer wird der Anforderungswunsch mit dem 
maximalen (minimalen) Anforderungswunsch oder der durchschnittliche 
Anforderungswunscli der Anforderer ermittelt. 

Priorisierungsverfabren nach Anspruch 12, 
dadurch gekennzeichnet, 

dass zur Ermittlung des rhaximalen (minimalen) Anforderungswunsches: 

der erste abgefragte Anforderungswunsch zwischengespeichert wird, 
jeder abgefragte Anforderungswunsch mit einem zwischengespeicherten 
Anforderungswunsch verglichen wird, ob er grdBer (kleiner) ist als ein 
zwischengespeicherter Anforderungswunsch, 

der abgefragte Anforderungswunsch zwischengespeichert wird, falls er grSBer (kleiner) 
ist als der zwischengespeicherte Anforderungswunsch und andernfalls keine 
Speicherung erfolgt, 

nach der Abfrage aller Anforderer der maximale (mimmale) Anforderungswunsch 
zwischengespeichert ist und weitergeleitet wird. 

Priorisierungsverfabren nach Anspruch 12 oder 13, 
dadurch gekennzeichnet, 

dass bei bestimmten Anforderern, z. B. Anforderer, die Motor und Bremse ansteuern, mit 
einem bestimmten Anforderungswunsch, z. B. einem Bremseingriff, der minimale (maximale) 
Anforderungswunsch, z. B. der minimale Vortriebswunsch, ausgewahlt wird und andernfalls 
der maximale (minimale) Anforderungswunsch. 

Priorisierungsverfahren nach einem der Ansprtlche 12 bis 14, 
dadurch gekennzeichnet, 

dass einzelne Anforderer bewirken, dass bestimmte andere Anforderer bei der Ermittlung des 
maximalen (minimalen) Anforderungswunsches nicht berUcksichtigt werden, z. B. ein 
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Anforderer-Fahrpedal bewirkt, dass alle Anforderer, die eine Bremsung/VerzOgerung bewirken, 
nicht berucksichtigt werden. 

16. Priorisierungsverfahren nach einem der AnsprUche 12 bis 15, 
dadurch gekennzeichnet, 

dass verschiedene Listen zum Anpassen auf globale Optinrienmgskriterien, z. B. 
Okoabstimmung, Sportabstirnmung oder Wintererkennung, abgearbeitet werden. 

17. Priorisierungsverfahren nach einem der AnsprUche 12 bis 16, 
dadurch gekennzeichnet, 

dass jeder Anforderer bzw. Plug-In durch eine Identitat (ID), vorzugsweise als Zahl, fur das 
Abarbeiten eindeutig gekennzeichnet ist. 

18. Priorisierungsverfahren von Informationsgebern, z. B. Plug-Ins, nach einem der Anspruche 8 
bis 17, 

dadurch gekennzeichnet, 

dass das (erste) Priorisierungsverfahren nach einem der Ansprttche 8 bis 11 mit dem (zweiten) 
Priorisierungsverfahren nach einem der Ansprttche 12 bis 17 kombiniert wird, z. B. indem das 
zweite Priorisierungsverfahren erst angewendet wird, falls das erste Priorisierungsverfahren 
keinen Anforderungswunsch liefert. 

19. Verfahren zur Steuerung, insbesondere zur koordinierten Antriebsstrangsteuerung eines Fahr- 
zeuges, insbesondere durchgefuhrt mit einem Computersystem nach einem der Ansprttche 1 bis 
7 oder 25 bis 29 mit im Wesentlichen den nachfolgenden Schritten bzw. Phasen: 

Charakterisierung der Umwelteinflttsse, 

Festlegen eines globalen Optimierungskriteriums, z.B. sportlich, dkonomisch oder 

verschleifischonend, 

Fahrerwunschinterpretation, 

Bestirnmung des optirnalen Betriebspunktes und 

Anfahren des optirnalen Betriebspunktes. 

20. Verfahren nach Anspruch 1 9, 
dadurch gekennzeichnet, 

dass zur Charakterisierung des Umwelteinflusses aktuelle Umweltdaten aufbereitet und ggf. 
typisiert werden, z. B. FahrzeuggrtJBen (Geschwindigkeit, Querbeschleunigung), 
Triebstrangzustand (Rraftschluss und Schub/Zug), Fahrertyperkennung (sportlich oder 



WO 2004/014700j 




PCTVDE2003/002541 



Ckonomisch durch Ableiten aus dem Fahrverhalten), Fahrsituationserkennung (Berg, Kurve, 
Winter, Stadt, Autobahn). 

2 1 . Verfahren nach Anspruch 1 9 oder 20, 
5 dadurch gekennzeichnet, 

dass bei der Fahrerwunschinterpretation eine Vorgabe fiir eine LSngsbewegung eines 
Fahrzeuges, z. B. der Fahrpedalinterpretation nach BeschleuiugungA/erzogerung und/oder den 
Vorgaben eines Fahrgeschwindigkeitsreglers oder ACCs, abgeleitet wird, wobei eine 
SystemfuhrungsgrGfie Getriebeausgangsmoment in eine GrOBe Getriebeausgangsmoment ftir 
1 0 den Antriebsstrang und eine GrOfie Fahrzeugverzogerung fur die Bremse aufgeteilt wird. 

22. Verfahren nach einem der Anspruche 19 bis 21, 
dadurch gekennzeichnet, 

dass zur Bestimmung eines optimalen Betriebspunktes fiir ein Getriebeausgangsmoment ein 
15 bestirnmtes Motormoment und eine bestimmte Getriebeubersetzung ermittelt wird. 

23 . Verfahren nach einem der Anspruche 1 9 bis 22, 
dadurch gekennzeichnet, 

dass das Anfahren des optimalen Betriebspunktes in einer bestimmten Zeitspanne zur 
2 0 Dampfung, z. B. fiir Fahrbarkeit, Komfort, Sicherheit und Aggregateschutz, erfolgt. 

24. Verfahren nach einem der Anspruche 19 bis 23, 
dadurch gekennzeichnet, 

dass die Aufgaben der Phasen von Koordinatoren in einem Layer nach einem der Anspruche 1 
25 bis 7 bearbeitet werden und die Inhalte der Phasen von Plug-Ins tiber Schnittstellen ermittelt 

werden, wobei die Plug-Ins vorzugsweise tiber ein Priorisierungsverfahren nach einem der 
Anspruche 8 bis 18 ausgewahlt werden. 

25. Computersystem mit wenigstens einem Prozessor und wenigstens einem Speicher zur 
30 Steuerung, insbesondere zur koordinierten Antriebsstrangsteuerung eines Krafrfahrzeuges, 

insbesondere zur Durchfuhrung eines Verfahrens nach einem der Anspruche 19 bis 24, mit 
einem objektorientierten Softwaresystem (Fahrzeug, Vehicle) mit im Wesenthchen folgenden 
objektorientierten Komponenten: 

Fahrzeugbewegung (V ehicle Motion, VM), 
35 - Antriebsstrang (Powertrain, PT), 

Fahrzeugkoordinator (Vehicle Coordinator, VCT), 
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Infogebern, z. B. UmweltgrtiBen (Environment Data, ED), ZustandsgrflBen (Driving 
Condition Data, DD), FahrzeuggrflBen (Vehicle Data, VD), und BenutzergroBen (User 

Data, UD), 

wobei diese objektorientierten Komponenten mit Schnittstellen nach innen und auBen (Interface 
In and Out) und einem Kriterienkoordinator (Criteria Coordinator, CC) zur Abfrage von Plug- 
Ins kommunizieren. 

26. Computersystem nacb Anspruch 25, 
dadurch gekennzeichnet, 

dass die Komponente Fahrzeugbewegung z. B. die Komponenten Traktions- und 
Fahrstabilitatssysteme (ESP), Fahrbewegungskoordinator (Vehicle Motion Coordinator, VMC) 
und Vortrieb/Bremsen (Propulsion/Brake, PrB), aufweist. 

27. Computersystem nach Anspruch 26, 
dadurch gekennzeichnet, 

dass die Komponente Vortrieb/Bremse, z. B. die Komponente Triebstrang (Propulsion System, 
PrSy), Bremssystem (Brakesystem, BrSy) und einen Vortriebs- und Bremskoordinator 
(Propulsion and Brake Coordinator, PrBC), mit einer Komponente Beschleunigungsaufteiler 
(Acceleration Request Manager, AccRM) aufweist. 

28. Computersystem nach einem der Ansprtiche 25 bis 27, dadurch gekennzeichnet, 

dass die Komponente Antriebsstrang, z. B. die Komponenten Antriebsstrangkoordinator 
(Powertrain Coordinator, PTC), Motor (Engine, Eng), Getriebe (Transmission, Tra) und den 
Infogeber TriebstrangzustandsgrOBen (Powertrain Data, PD) aufweist. 

29. Computersystem nach einem der AnsprQche 25 bis 28, dadurch gekennzeichnet 

dass, der Kriterienkoordinator mit einer Anwendungsschnittstelle (Application Programming- 
Interface, API) kommuniziert. 

30. Verfahren nach einem der Ansprttche 19 bis 24 durchgefuhrt mit einem Computersystem nach 
einem der Ansprtiche 25 bis 29 mit im Wesentlichen folgenden Schritten: 

zur Charakterisierung der Umwelteinfltisse, die aktuellen Umweltdaten bzw. 
ZustandsgrOBen in Infogebern zugewiesen werden, worauf alle anderen Komponenten 
zugreifen k&nnen, ausgenommen die TriebstrangzustandsgrSBen, worauf nur der 
Antriebsstrang zugreifen kann, 
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vom Fahrzeugkoordinator das Festlegen eines globalen Optimienmgskriteriiims 
gesteuert wird, welcher VorschlSge tlber den Kriterienkoordinator von ausgewahlten 
Plug-Ins abfragt, 

vom Vortriebs- und Bremskoordinator die Fahrerwunschinterpretation gesteuert wird, 
5 welche in Zusammenarbeit mit ausgewShlten Plug-Ins tiber den Kriterienkoordinator die 

Vorgaben ftlr Bremse und Antriebsstrang ennittelt, wobei vorzugsweise der 
Fahrbewegungskoordinator diese Vorgaben mit den Traktions- und 
Fahrstabilitatssystem koordiniert und die Vorgaben an den Triebstrang bzw. das 
Bremssystem weitergegeben werden, wobei uber die Anwendungsschnittstelle z. B. eine 
10 Fahrzeugsollbeschleunigung in ein Getriebeausgangsmoment umgerechnet wird und an 

den Antriebsstrang weitergegeben wird, 

vom Antriebsstrangkoordinator zum Bestirnmen des optimalen Betriebspunktes ttber 
den Kriterienkoordinator Plug-Ins ausgewShlt werden und der 
Antriebsstrangkoordinator mit den Plug-Ins Uber den Kriterienkoordinator 
15 kommuniziert 

3 1 . Verfahren nach Anspruch 30, 
dadurch gekennzeichnet, 

dass die Auswahl der Plug-Ins mit einem Priorisierungsverfahren nach einem der Ansprtlche 8 
20 bis 1 8 ausgeftihrt wird. 

32. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach einem der 
Ansprttche 8 bis 24 oder 30 bis 31 durchzufuhren, wenn das Computerprogramm auf einem 
Computer oder einer entsprechenden Recheneinheit durchgefuhrt wird. 

25 

33. Computerprogrammprodukt mit Programmcodemitteln, die auf einem lesbaren DatentrBger 
gespeichert sind, um ein Verfahren nach einem der Ansprtlche 8 bis 24 oder 30 bis 3 1 
durchzufuhren, wenn das Computerprogramm auf einem Computer oder einer entsprechenden 
Rechnereinheit ausgeftihrt wird. 



30 
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Funktionale Architektur: 
Wie verhalten und ordnen sich Fahrzeugfunktionen zueinander? 



Software Architektur: 
Wie werden Fahrzeugfunktionen in Software implementiert? 



Netzwerk Architektur: 
Wie kommunizieren verschiedene Hardwareteile miteinander? 



Hardware Aufteilung: 
Auf welcher Hardware sollen Fahrzeugfunktionen laufen? 
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FIG. 8 
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FIG. 13 
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FIG. 16 
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Beispiel: 


VC: 


CC Get_VehOpt(ID1) 


Critl: Winter, wird aktiv, wenn 
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Critl _GetVehOpt() 


die Fahrsituation ..Winter" 


Critl: 


return (None) 


erkanntist. 
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FIG. 18 



Ablaut: 

PrBC: 

CC: 

Critl: 

CC: 

PrBC: 

AccRM: 

PrBC: 

CC: 

Crit2: 

API: 

PT: 

API: 

Crit2: 

CC: 



Belspleb 

CC_Get_DriveProp(ID1) Critl: FGR, fordert Sollbeschleunigung, 



Crit1_Get_DrivePropO 
zuv&k(1.1 m/s 2 ) 

zu*&b(1>1 m/s 2 ) 

AccRM_Calc(1.1 m/s 2 ) 
zwn&k(160Nm, 0 m/s 2 ) 

CC_Get_DriveProp(ID2) 
Crit2_Get_DrivePrppO 
API_Get_Trq(+1.2m/s 2 ) 
PT_Get_Trq(+1.2m/s 2 ) 

2Uv»ck(170 Nm) 

Zuwick (170 Nm) 

au*&ek(170 Nm,0m/s 2 ) 

ZuvSeMl70 Nm, 0 m/s 2 ) 



wenn FGR aktiv ist 

Crit2: Beschleunigungspedal, 
Fahrpedalinterpretation 
als Beschleunigung 

Crit3: Standart, Fahrpedal- 
interpretation als Moment 



ERSATZBLATT (REGEL 26) 



WO 2004/014700 



13/15 



PCT/DE2003/002541 



FIG. 19 

Schnittstelle: 

Aufruf: Crit_Get_DrivePropO 
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| Vortriebsmoment M Vortrieb und Bremsbeschleunigung a Brems 
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1 = Anforderung besteht aus M Vortrjeb und a Brems 

2 = Anforderung ist a Summe 
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FIG. 21 
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